Dear Werner, you wrote:
No, this is a misunderstanding. I want a library of artificial characters which combines base characters and accents to composite characters, e.g.
.fchar \[u0041_0304] \Z'<shift \[a-] to the right position>'A .fchar \[-A] \[u0041_0304]
Those macros should work for all platforms and -- if possible -- for all typesetting devices. Most device specific startup files already have support for that, e.g., `.ps-achar' or `.dvi-achar'. Using these macros the repertoire should be extended to cover a broad range of Unicode characters.
Such substuitution, if done properly, has to be font-dependent and resorted to only if the font
lacks precomposed characters.
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?
The use of font-specific tables seems to be the modern way to typeset composite characters.
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.
But as far as it is not a problem of making groff read decomposed utf-8,
but an issue of enhancing groff typesetting capabilities using the minimal set of fonts -
is is not that interesting for me, since Russian is not covered by base 14 fonts and does not
use composed characters anyway.
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)?
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.)
In the days of pdf's with all (including base) fonts included,
constructing ugly (but portable) Amacron from Times,
instead of taking a ready-made Amacron from TimesNewRoman may be
appreciated by some infinitesemal minority of users.
Given the size of the groff user base using Amacron that may be less than one ;)
And if there is such Amacron user community - then they have fonts with Amacron
installed.
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.
And what do you call "all output devices"?
Are there any devices in use but ps, html and tty in different encodings?
The good old days, when men were men and wrote their own drivers for the devices they possessed,
are long gone :(
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.)
Please, take note of the mail from Andrey Borzenkov.
He demonstrates the incompleteness of devutf font description files with respect to Russian.
But the same problem arises for that Amacron - "can't find special character u0041_0304"
in both utf and html output devices.
Sincerely, Michail
_______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
