[XeTeX] XeTeX (/not/ XeLaTeX) : Marginal kerning, font protrusion, hyperlinks

[Philip Taylor]

Hallo both --

Will Robertson wrote:

> I’ve been away from LaTeX development work for a while; I’ve been known to let primitives slip through the cracks.
> Thanks for letting us know — I wouldn’t be surprised if there were some more we overlooked.
>
> These commands are all described in the pdfTeX manual, and I’ve now added some (fairly brief) details to xetexref (attached).
>
> Khaled, would you be able update the copy in the xetex repo?

I also have some input from Thanh, which I was intending to flesh out
(noting in particular the microtypographic primitives that have /not/
been ported from PdfTeX to XeTeX) but as I am tied up until Sunday
I append what I already have, and can co-operate with you both to
discuss a final wording from Sunday onwards.

** Phil.
--------

Margin kerning (aka character protrusion) in XeTeX was ported from 
pdftex. The following was copied from the PdfTeX manual with some 
modification for XeTeX.

\XeTeXprotrudechars
Margin kerning is a technique to allow certain characters to move into 
the margin (aka "character protrusion").  When \XeTeXprotrudechars = 1, 
the glyphs qualified as such will make this move when applicable, 
without changing the line-breaking.  When \XeTeXprotrudechars = 2 (or 
greater), character protrusion will be taken into account while 
considering breakpoints, so line-breaking might be changed.  This 
qualification and the amount of shift are set by the primitives \rpcode 
and \lpcode. Character protrusion is disabled when \XeTeXprotrudechars = 
0 (or negative). If you want to protrude some item other than a 
character (e.g., an \hbox), you can do so by padding the item with an 
invisible zero-width character for which protrusion is activated.

\rpcode
The amount that a character from a given font may shift into the right 
margin ("character protrusion") is set by the primitive \rpcode.  The 
protrusion distance is the integer value given to \rpcode, multiplied 
with 0.001 em from the current font.  The given integer value is clipped 
to the range -1000 .. 1000, corresponding to a usable protrusion range 
of -1 em .. 1 em. Example:

\font \x = cmr10
\rpcode \x`, = 200
\rpcode \x`- = 150

Here the comma may shift by 0.2 em into the margin and the hyphen by 
0.15 em.  All these small bits and pieces will help XeTeX to give you 
better paragraphs (use \rpcode judiciously; don't overdo it).

The above example was for TFM fonts. For non-TFM (i.e., native
TrueType/OpenType) fonts, instead of a character code (8-bit number) 
\rpcode accepts either a Unicode character code (prefixed by the keyword 
"unicode"), a glyph name (prefixed by "name"), or a glyph number [1]. 
Thus, in the example:

     \font \x = "Charis SIL" at 10pt

     \rpcode \x unicode "2C = 100
     \rpcode \x name "comma" = 100
     \rpcode \x 15 = 100

the three \rpcode lines all have the exact same effect, as the comma
glyph in this font has glyph ID 15.

In most cases, setting character protrusion values via Unicode 
codepoints will be the simplest and most robust approach; glyph names 
and glyph IDs are provided for cases such as contextual forms that are 
not directly accessible via Unicode character codes.

\lpcode
This is similar to \rpcode, but affects the amount by which characters
may protrude into the left margin.

 > Is it therefore the case that the only three primitives that are
 > relevant to microtypography which have been ported to XeTeX are :
 >
 >>>          \XeTeXprotrudechars
 >>>          \rpcode
 >>>          \lpcode

yes

 > What of (for example)
 >
 >>>          \leftmarginkern
 >>>          \rightmarginkern
 >>>          \pdffontexpand
 >>>          \pdfadjustspacing
 >>>          \efcode
 >
 > etc ?

not implemented. I started to implement font expansion sometime ago
but could not finish it due to lack of time

 > Also, are you able to offer any insights into the questions of
 > unitless codes v. <dimen>s that I raised ?
 >
 >
 >>> Why the last parameter to \rpcode and friends are codes and not
 >>> <dimen>s ? In other words, of the final parameter to \rpcode is a
 >>> unitless number that actually represents 0.001 em; why not let
 >>> there be an (e.g.,) an \rpwidth such that one could write (for
 >>> example)
 >>>
 >>>          \def \TeXtoUnicode {U}
 >>>          \XeTeXprotrudechars = 2
 >>>          \rpwidth \fd \TeXtoUnicode `\- = 0,25 em
 >>>          \rpwidth \fd \TeXtoUnicode `\. = 0,15 em
 >>>
 >>> rather than the unitless (and therefore apparently arbitrary)
 >>>
 >>>          \def \TeXtoUnicode {U}
 >>>          \XeTeXprotrudechars = 2
 >>>          \rpcode \fd \TeXtoUnicode `\- = 250
 >>>          \rpcode \fd \TeXtoUnicode `\. = 150
 >>>
 >>> as at present ?

it makes more sense to specify margin kerning in proportion to em. If
you prefer to specify dimen, it's a simple exercise of macro
programming to implement \rpwidth using \rpcode.

Thanh.


[1]

CHECK THIS :  IS "unicode" allowed or only "U"/"u", and is "name" 
allowed or only a forward slash ?

JK (http://tug.org/pipermail/xetex/2010-May/016531.html) says "The 
keywords used to specify \lpcode and \rpcode values for native-font 
glyphs have been changed to be more concise, and also more similar to 
forms used in other contexts. Unicode character codes are now prefixed 
by "U" (or "u"), and glyph names by "/" (slash), just like glyph names 
in Type 1 encoding files. So this means that protrusion values for 
native fonts can be set as
"