Re: Pango development trouble (Kerning - PLEASE HELP!)

["Trever L. Adams" <tadams-lists myrealbox com>]

On Mon, 2003-11-17 at 11:53, Owen Taylor wrote:
> On Sat, 2003-11-15 at 08:42, Trever L. Adams wrote:

> My instinct is that this should be handled at the layout or driver
> layers, not at the shaper or backend layers.
> 

Yes, I have recently come to the same conclusion.

> To implement justification, the higher layers need to know where 
> space can be added in the line. Once we have that information, adding
> a manually specified amount of space should be trivial.
> 

On the kerning, it may be negative, not just positive.  It also needs to
not be modified by the justification.  For example, and a rare one, you
may use kerning (or tracking) to put the T in OT inside the O.  That is
a bad example, but that kind of stuff is done.

My latest idea was to hack the width in a fake way so that the kerning
was done in much the same way as it was done in backend.  It would
require a hack on the line length, but I was going to add a flag to
glyphlist (PangoGlyphVisAttr, I believe) that was something like
fake_width, so if kerned pairs didn't totally fit on a line, it could
look up the real width of the character using a call to the backend.

> The way the that justification needs to work is to add flags to 
> PangoGlyphVisAttr indicating the properties of the position before
> the glyph; it gets a little complicated because of:

Ok, yes, kerning/tracking and justification could indeed be all done by
the same code.  Here is my understanding of justification:

LEFT/RIGHT/CENTER only move where on the line you start from (this is
somewhat already done w/ the LtoR and RtoL text directions), they do not
modify spaces, etc.

However, FULL justification modifies the spacing.  In most programs I
have ever used, most of this is stuffed into white space characters, but
I am not sure this is the right way to do this.

> 
>  - You may want a hierarchy where some places are better than 
>    others to add space and you add space in those places first.

I believe I started asking this question above.

>  - Arabic justification with Kashida
> 

Is this the only major script that has this quirk?  And yes, I have
absolutely no clue what issues there are with different scripts on
justification.

> But it's possible that for now we can just add a simple "can add
> space here" flag, if we don't have anybody interested in doing the
> research to come up with a full solution.

If I can get a working solution in that doesn't address this completely
first, I am willing to do the research as best as I can.  It may take a
while.

> 
> > I have removed the absolute kerning from the patch.  It is not relative
> > using em, much like the rise functionality works.  This also simplifies
> > my patch tremendously.
> 
> I can't quite follow this. 'rise' is in device units, not relative to
> the font size, and I'd expect a kerning/tracking adjustment to be the
> same way.
> 
> [...]

Ok.  According to the Pango docs, rise is in thousandths of an em.  Em,
by definition is the size of the letter M in a given face/size
combination.  Of course, most people now take the definition in a way
that em is the same as the point size.  So, if rise is in thousandths of
an em, it is relative and is NOT in device units.  Can you clarify the
documentation for me?  (It seemed to be that it is indeed em's when I
was playing with it for clarification the other night.)


> Markup for Pango is (almost) an XML subset. It certainly follows the
> XML nesting rules.

Good.  I am glad to hear it.


> The i. While it doesn't really matter here, if we use a consistent 
> principle that properties on the character after applies to the
> space before, that allows to set properties on the spaces before
> and after the string. (Since PangoAttributes have a range of 
> O => MAXINT)

Alright, I will follow this rule.  It goes after.

>  
>  A B C
> ^ ^ ^ ^ 
> 
> While using the character before wouldn't allow setting properties
> on that first position.
> 
> > So, two questions, how can I get this kerning data (just an integer) to
> > be added to every GlyphItem in the Layout functions so that it is
> > available in the kerning function way down in?  And 2) How do people
> > want this tag to work?
> > 
> > People, we really need this functionality if we want Pango to be worth
> > much.  Yes, it is great as is, but this is needed.
> 
> Wow, what hyperbole! :-) Manual kerns are occasionally useful, but
> way behind, say, justification and hyphenation in terms of typographic
> features that Pango doesn't yet support.

Maybe in your book.  I am working with a graphic designer on a few
projects.  This is what he wanted tackled first.  It also is showing up
in a project of my own.  Kerning, tracking, whatever the heck you want
to call it is indeed something I need more than justification or
hyphenation. (I always hated where most automatic-hyphenators put
hyphens!)  I can only speak from my personal experience and from what
the people I work with tell me.

Also, if my understanding of justification (which is based on using
NON-DTP apps) is correct, the only justification that will be difficult
is FULL.  I have copied my friend who is a graphic designer on this,
hopefully he can clarify all of these issues for me/us.

> 
> I actually don't think "kerning" is a good name here ... in the computer
> world, it usually gets used to refer to binomial kerning tables. 
> (kerning pairs)
> 

Ok, tracking is good then.  The problem with using it is it applies to a
set change from the automatic kerning to the output.  It doesn't replace
it.  At least, this is my best understanding of it.  I believe it may
also take the form of a percentage of the automatic kerning, not a hard
value added to or from it.

> "tracking" might be a better term to use here, especially since 
> you can set it over spans of text ("letter spacing" is another term
> that could be used.)
> 
> An interesting question is what is the interaction of this with
> automatic kerning... does it apply after the automatic kerning
> or replace it? If it applies after (which seems easier), do we
> need some separate way to suppress the automatic kerning?
> 

This is why I wanted the data in the backend or shaper.  Manual kerning
COMPLETELY replaces the kerning provided by the font.  I was just going
to undo it in the cases necessary by adding a function in the
appropriate place to get the value to subtract from the width, since I
couldn't get the info in the backend.

So, yes, justification, kerning, tracking, etc. all have similar code,
but justification can't modify the manual kerning.  Tracking is a
"fixup" of the automatic kerning (and is the most similar to
justification), kerning is a complete replacement of the automatic
kerning, not a fixup (absolute +/- or % multiplier).

> Regards,
> 						Owen
> 

Now, if I am wrong in my understanding, please clarify.  I am sure my
friend will.  If you all can give me some time before 1.4 is released, I
can try to get all of these in, once we get them clarified.

Thank you,
Trever

--
"Perilous to all of us are the devices of an art deeper than we possess
ourselves." -- Gandalf the White [J.R.R. Tolkien, "The Two Towers", Bk
3, Ch. XI]