Hi,
When an input file contains the character , 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 ,
preconv transforms it to x\[u0302]\[u0301], and troff produces three distinct
glyphs x, u0302, u0301
Dear Bruno,
On Tue, 21 Feb 2006, Bruno Haible wrote:
When an input file contains the character , 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 ,
preconv transforms it to x\[u0302]\[u0301], and
> When an input file contains the character , 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
> , preconv transforms it to
> x\[u0302]\[u0301], and troff produces three distinct glyphs x,
>
> > Currently, groff only recognizes a very limited set of
> > ligatures (fi, ff, etc.)
>
> Ah, good example! This is already an precedent where groff combines
> adjacent input nodes. When the user doesn't want the ligature, he
> can use \& as a separator between the two, right?
Correct. On the
Hello Werner,
> it's probably something which should be done later.
Well, I'm on it now because I feel more comfortable dealing with the CJK
width and other smaller problems once the logic of decomposition and
combined characters is done right.
> Currently, groff only recognizes a very limited s
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 s
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 fr
> 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
> > Currently, there is a single non-spacing glyph used in groff
> > (`slashnot' in devdvi; the other non-spacing glyphs from the
> > various DVI fonts have no names), and this has to be placed before
> > the base character. Additionally, it isn't a valid Unicode
> > character so there is no conf
> > When an input file contains the character , 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
> > , preconv transforms it to
> > x\[u0302]\[u0301], and troff produces three distinct
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 s
Werner LEMBERG wrote:
Independently of this I think I think it would be a nice idea to
extend afmtodit so that it supports `CC' (and `PCC'). ...
Do you want to work on this? On the other hand, it's probably not
worth the trouble since AFM files with `CC' directives are rare (and
AFM is dying
On 2/25/06, Larry Kollar wrote:
>
> How much work would it be to hook into whatever system-wide printer
> drivers there may be?
A lot.
> This is something I've been pondering for a
> while, and I don't even have a clue how gtroff figures out glyph
> widths (is there some communication between gtr
> How much work would it be to hook into whatever system-wide printer
> drivers there may be?
Uh, I've no idea.
> This is something I've been pondering for a while, and I don't even
> have a clue how gtroff figures out glyph widths (is there some
> communication between gtroff & the postproces
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 access
> >> 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.
16 matches
Mail list logo
