It would be nice to have access to all the TrueType and
PostScript fonts installed on the system without having to build
metric files and so forth.
This is virtually impossible IMHO. You need a tight integration
between groff and the OS, making it highly system-specific.
I don't
Werner LEMBERG wrote:
... how gtroff figures out glyph widths ...
gtroff reads the metric files (in the devXXX directories) for the
given device and positions the glyphs accordingly. The postprocessor
just translates the intermediate output file into device-specific
data -- no need to
When an input file contains the character U+1EBF, preconv
transforms it to \[u1EBF], and troff transforms it to a single
glyph u0065_0302_0301. Fine.
But when an input file contains the characters
U+0078U+0302U+0301, preconv transforms it to
x\[u0302]\[u0301], and troff produces
Werner Lemberg wrote:
Please be careful! Unicode gets extended from time to time, and there
are high chances that new non-spacing diacritics are added.
Consequently, a solution within groff must be based on
user-controllable data.
I suggest to (re)use
.composite foo
(just a single
Michail Vidiassov wrote:
Fine, wrong - may be the answer is it depends
(on the availability of the precomposed glyph in the font)?
No, it shouldn't depend on that. troff does an early pass where is
constructs a precomposed glyph from the base character and the combining
characters, and should
Hello Werner,
So I imagine that noone will object if troff combines
x\[u0302]\[u0301]
into
\[u0078_0302_0301]
I think this is OK. Currently, there is a single non-spacing glyph
used in groff (`slashnot' in devdvi; the other non-spacing glyphs from
the
But there are already 418 characters with non-trivial combining classes
listed in
http://ftp.unicode.org/Public/5.0.0/ucd/extracted/DerivedCombiningClass-5.0.0d10.txt
Will the startup time penalty to register all these one by one be
acceptable?
I think so. Compare this to LaTeX,
Dear Bruno,
On Tue, 21 Feb 2006, Bruno Haible wrote:
When an input file contains the character U+1EBF, preconv transforms it
to \[u1EBF], and troff transforms it to a single glyph u0065_0302_0301. Fine.
But when an input file contains the characters U+0078U+0302U+0301,
preconv transforms it
When an input file contains the character U+1EBF, preconv
transforms it to \[u1EBF], and troff transforms it to a single glyph
u0065_0302_0301. Fine.
But when an input file contains the characters
U+0078U+0302U+0301, preconv transforms it to
x\[u0302]\[u0301], and troff produces three
