Re: [Groff] ubuntu, groff and utf-8

[Werner LEMBERG]

> > I want a library of artificial
> > characters which combines base characters and accents to composite
> > characters, [...]
> 
> Such substuitution, if done properly, has to be font-dependent and
> resorted to only if the font lacks precomposed characters.

Right.  This is what the `.fchar' request does, contrary to `.char'
which always overwrites the font's definition.

> AFAIK, opentype fonts have tables of relative positions of accented
> characters and accents, AFM files can have a section describing the
> construction of composites.  Can groff use that information?

No.  It shouldn't be too difficult to write a script which transforms
such information into proper .fschar commands.  Similar to LaTeX, this
data could be in a foo.fd file; more sophisticated font loading macros
could automatically load such a file if it exists.  On the other hand
I'm not sure that it is worth the trouble.  You are the first one who
has ever mentioned this AFM feature on the groff list.

> The use of font-specific tables seems to be the modern way to
> typeset composite characters.

For such font-specific changes you can use the `.fschar' request which
defines a glyph for a specific font only.

> Managing composites in device-specific (instead of font-specific)
> way looks to me like a dead end.  On the other hand, there may be no
> popular demand for such feature.

Well, it is non-trivial to add such support to the Type 1 handler,
while we can support that already on the macro level.

> BTW, what about creating a new output device, "psunicode", relying
> not on the usual postscript fonts, but on the Miscosoft/Monotype
> TrueType fonts or some other downloadable (if not redistributable)
> fonts with a good coverage of extended latin, cyrillic, math and
> technical symbols (i.e. everything groff can typeset)?

Why do you want a new output device if you just have to install new
fonts?  In my local setup I've added the URW fonts (from ghostscript)
which have Cyrillic glyphs also -- your afm2dit changes work great!
Since those fonts are currently of rather bad quality and are changing
frequently I hesitate to add them to the groff package by default.

> Abundant precomposed characters already in the font may be a way
> around the lack of composition support in groff. (E.g. no need for
> artificial Amacron when such glyph is already in the font.)

Well, my idea is to have fallback glyph definitions.

> One more thought - that artificial Amacron you want to have will not
> be recognised as such by ps converters to text or pdf, thus making
> the output distorted or less searchable.

That's true, but it's not always possible to use a font which has a
real Amacron...

> And what do you call "all output devices"?

I've written `all typesetting devices', this is, where groff controls
the actual layout, and where glyphs are used in the output: X, ps,
lbp, and dvi.

> As to la and ra mapping - as far as I can see, the most popular
> console font, Lucida Console, does not have that math angle
> brackets. None of the default Mac OS X fonts has them.  If la and ra
> are not math symbols by design - let them be mapped to the 2039 and
> 203A (in the text mode at least). If they are - change .URL to use
> fo and fc instead.  (It is only my HO, of course.)

The very problem of such mappings is that they must be done locally.
The -Tutf8 device produces *font independent* output, this is, it
outputs characters, not glyphs.  groff simply doesn't know which
console font is finally used.  If you want to change the mappings,
they must be put into your local troffrc file.  I missed that in my
last reply.

With other words, I won't change them in the src package (since the
mappings are correct), but distributions should provide local changes
to be in sync with the used console fonts.

> Please, take note of the mail from Andrey Borzenkov.  He
> demonstrates the incompleteness of devutf font description files
> with respect to Russian.

This is fixed now for devutf8 and devhtml.  Please see my other mail
with grohtml problems.

> But the same problem arises for that Amacron - "can't find special
> character u0041_0304" in both utf and html output devices.

Yeah, I'll add support for that also.


    Werner