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

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-11-17 at 12:35, Trever L. Adams wrote:

[...]

> > 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 width field in PangoGlyphVisAttr is precisely the advance to the
next character. There is nothing hacky about adjusting this.

> > 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.

In old-fashioned typesetting terminology, "justification" meant
"full justification". "Ragged-right" and "Ragged-left" were used
for "left justified" and "right justified"

The Pango API and terminology is:

typedef enum {
  PANGO_ALIGN_LEFT,
  PANGO_ALIGN_CENTER,
  PANGO_ALIGN_RIGHT
} PangoAlignment;

void pango_layout_set_alignment (PangoLayout    *layout,
                                 PangoAlignment  alignment);
void pango_layout_set_justify   (PangoLayout    *layout,
                                 gboolean        justify);


Alignment hs worked forever. Justification is not currently implemented.

> >  - 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.

Kashida insertion is found pretty much exclusively for Arabic and Syriac
for currently used scripts. I think most other scripts pretty much
follow the latin model of white space insertion, though there certainly
are quirks:

 - Some scripts insert white space at word boundaries, though they
   are written without word boundaries at normal width (Thai, I believe)
 - Some scripts do not distinguish word boundaries (Han script)

> > > 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.)

The code is going to be more authoritative than the docs. There's
nothing in the code to implement it relative to an em.

(Any reference to "thousandths" in the docs is a giveaway of really old
and out-of-date docs, since PANGO_SCALE has existed with the value
1024 for quite some time.)

Could you file a bug against the docs.

[...]

> 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.

[ Unless you Bcc'ed him, perhaps you forgot the Cc ]

> > "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.

I think "how Pango  would lay it out normally" is a lot easier to define
then "unkerned".

If you turned off kerning, would you also turn off:

 - GPOS positioning from OpenType tables in the font
 - "grid-fit kerning" technique described in 
  
  http://people.redhat.com/~otaylor/grid-fitting/

To me, wondering about whether the manual kerning adjustment is 5pt
or 12pt is pretty much irrelevant ... any reasonable interface for it
would be graphical.

> 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).

I'm interested in the reference you have for these usages,
I've seen these terms used in quite a few different ways, nothing
as definite as the definitions you seem to be familiar with.

> 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.

I have to say I think that working on this may be a bit premature. 
I think we need to do justification first, then look at tracking /
manual kerning. Probably unlikely we'll get either in for 1.4, but
if we can get 1.4 out quickly, then we'll all be set for adding cool
features for 1.6 :_-)

Regards,
						Owen