boundary char and implicit kerns

[Hilmar Schlegel]

Han The Thanh wrote:
> 
> > > I think that kerns with respect to the space in some font are not intended
> > > for hanging certain characters, but simply to make the interword space not
> > > to look so large when the adjacent char is a period or a comma.
> >
> > So we've to make the definitions more clear:
> > You understand by hanging begin/end of line spacing adjustments as
> > described in The Book which must be achieved from within Tex by special
> > handling of the characters in question since Tex itself doesn't have a
> > mecahnism to detect if a character is placed at the line boundaries.
> > The boundarychar mechanism is working on the font-level and can be used
> > for various effects like initial/final character variants (via LIGs),
> > interword spacing (via KRNs) (more exact begin/end word spacing since it
> > applies the same way also to begin/end line spacings).
> > Finally hanging hyphenation (to make e.g. hanging puntuation complete)
> > can only be achieved on the font-level with the definition of an
> > alternative hyphenchar.
> >
> > >I am not
> > > sure about the real intention of the boundary char mechanism, but I think
> > > it's similar, ie for optical adjustment of interword spaces.
> >
> > In case you observe that hanging characters within Tex (based on
> > discarding repeated positve/negative spacings) doesn't work for
> > characters having kerns with the boundarychar means that instead of
> > discarding the space, which cancels the hangamount within a line, this
> > space is *not* discarded after a kern with the boundarychar. Is this
> > what you observe?
> > This indicates that discarding stops here for some reason - is it
> > possible there is something else slipping in the way from the macros for
> > the characters in question which tells Tex not to discard the following
> > items?
> 
> I do marginal kerning in pdftex. 

Fine!

> The mechanism detects whether the ending
> object of a line is a character, and inserts a kern if needed.

Since optical adjustment of overhanging characters like T, V, A is a
plausible idea at the ends of a line, there may indeed a kern which
isn't about to be removed the last object on a line.
I.e. these kerns are by purpose there and aren't to be removed (except
possibly for those characters which actually are defined to hang out).

One way for a short solution would be to make metrics files after
hanging characters are defined and remove all those critical kerns which
stop your algorithm from working.

> Now it stops
> to work when kerns with respect to interword space are used via the
> boundarychar, because when eg the comma ends up at the end of a line, there
> is still an implicit kern after it. Thus the comma is not "protruded"
> as it should be at all.

In this case the test must be carried out more reliable: to see if the
last *character* on the line is a comma or whatever. Furthermore the
additional kerns must be taken into account: either to compensate them
in the hangamount or adjust the hangamount accordingly.

BTW, how do you specifiy
i) which characters hang out
ii) how far they stick out
?

I hope you can cure this additional difficulty to get the advanced
feature of hanging characters for PDFTex to work in a reliable fashion.

Best wishes,
Hilmar Schlegel
###