[XeTeX] glyph index

franÿffffe7ois franc franc_milo at yahoo.fr
Tue Jan 20 18:34:59 CET 2009


dears Jonathan, Adam and others,

I know, that in icu-project, they haven't yet done any OpenType justification support yet;
so, I simulate this feature in a web code.
Adding APIs to OpenTypeLayoutEngine to discover the minimum and maximum
widths that a given word can have, and taking into account justification alternates, 
will be a second step. or it can be done using libotf library. 
I start with a prior knowledge that some glyph has alternatives with different widths.
and I'm focussing essentially the line break algorithm, in the adv_past subroutine of line_break routine, I make a parallel calculation; the first
based on the default width of the node, and the second using alternative glyph. in the end of line I will 
choose the best with the minimum demerit.
But I don't know how can I access to glyphs informations using xetex primitives within the web code.

 


--- En date de : Mar 20.1.09, Jonathan Kew <jonathan at jfkew.plus.com> a écrit :
De: Jonathan Kew <jonathan at jfkew.plus.com>
Objet: Re: [XeTeX] glyph index
À: "Unicode-based TeX for Mac OS X and other platforms" <xetex at tug.org>
Cc: franc_milo at yahoo.fr
Date: Mardi 20 Janvier 2009, 17h09

On 20 Jan 2009, at 15:40, franÿffffe7ois franc wrote:

> >Do you really mean that you want to substitute one *glyph* for
another, or do you want
> >to substitute a *character* in a certain context? Maybe you could give
a
> >real-life example to make it clear what you're trying to achieve.
> 
> Actually I'm trying to use jalt (justification alternative) of OT
font, to improve line
> justification, so I'm working to
>  modify the line breaking algorithm. thus I want that the
> substitution to be independent of the font engine.
> and the replacement happens only if that improves the line justification.

Ok, I see. In that case, I think you have several problems to worry about! This
is not a straightforward thing to do...

There are a couple of approaches to consider: you could choose line-breaks
first, based on the default widths of the words, and then use justification
alternates where possible to improve each individual line (this is the simpler
option, essentially done within the hpack() routine); or for the very best
results, at the cost of extra complexity, you could allow the availability of
the alternates to affect which line-breaks are chosen. This would be quite a bit
trickier, I think.

If you substitute a glyph from a 'jalt' feature, the positions of other
glyphs will need to be recomputed, and indeed other glyphs might need to be
substituted as well (e.g., if there are contextual alternates that vary
depending which glyph from 'jalt' is chosen). In general, you can't
just do the 'jalt' substitution after the rest of OpenType layout
processing has been done; that lookup needs to be applied at the proper place in
the overall sequence of OT lookups.

I think the best way forward will probably be to implement this as an extension
to the OpenType layout engine itself, rather than trying to do the justification
alternates as a separate step outside the main OT layout process. E.g., you
could add APIs to OpenTypeLayoutEngine to discover the minimum and maximum
widths that a given word can have, taking into account justification alternates,
and then use this information to help the line-breaking routine. Then, having
chosen the breaks, you'd have to set the appropriate 'jalt' features
on the words to get the best fit; only then can you get the final positioned
glyph data back from the layout engine.

Anything you do here should be designed to fit in with the ICU layout engine
APIs, and if possible, pushed upstream to the original ICU project. As far as I
know, they haven't yet done any OpenType justification support yet;
there's an open ICU ticket on this, but no activity AFAIK.
http://www.icu-project.org/trac/ticket/1072

JK




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tug.org/pipermail/xetex/attachments/20090120/eda43099/attachment.html 


More information about the XeTeX mailing list