> Here is what I came up with. Feel free to edit to
> your own taste or reject :)
Very nice, thanks! I'll apply it (possibly with slight changes) as
soon as I'm allowed to. You can find a copyright disclaimer in
another mail.
Werner
Hello, Werner.
Here is what I came up with. Feel free to edit to
your own taste or reject :)
Anton
--- groff.texinfo 2011-08-21 23:08:07.18750 +0400
+++ groff.texinfo.new 2011-08-27 01:04:15.546875000 +0400
@@ -6882,7 +6882,11 @@
@cindex manipulating hyphenation
@cindex hyphenati
> Therefore, the input character mapping file (like koi8-r.tmac) is
> not necessary for UTF-8 input. Just set hyphenation codes directly:
>
>.hcode \[u] x
My bad, sorry. I haven't looked into the documentation, and I've
mixed up .hcode and .trin. This essentially means that it is poss
Sorry, the later request should be:
.hcode \[u] x
Anton
Just as I thought I have finished the patch, I found
out I was wrong about the following piece:
Werner LEMBERG:
> > Therefore, I suppose that groff applies the ex-
> > isting character translations inversely to get
> > back to some simple characters. Then, hyphen-
> > ation codes can be com
Werner LEMBERG:
> > Frankly, yes :) -- add a warning to the descrip-
> > tion of the .tr request. Especially so, because
> > there are examples in the manual in which the
> > mapping is changed and then "restored" back. The
> > user should know the side effect of this opera-
> > tion.
>
> Tha
>> Well, \N'...' is kind of a glyph-only object, but by its very
>> definition you can't hyphenate it.
>
> What about a \[u0430] coming from a UTF-8 file processed by preconv?
> What corresponding input character does it have provided no
> character translations were used?
There are two possible
Werner LEMBERG:
> This is not possible. How shall come a glyph-only
> object into existence? I don't count ligatures
> and similar things here since they also need input
> characters to exist.
> [...]
> Well, \N'...' is kind of a glyph-only object, but
> by its very definition you can't hyph
>> OK, but the reference to the input character is allowed to be
>> 'null', then?
>
> This is not possible. How shall come a glyph-only object into
> existence? I don't count ligatures and similar things here since
> they also need input characters to exist.
Well, \N'...' is kind of a glyph-onl
> Now that I have acquired more understanding, I don't have problems
> reading the manual. But I had had a hard time before!
The standard documentation problem of developer vs. user...
>> Actually, it's the same object, containing a ref- erence to both
>> the input character and the corre- spon
Werner LEMBERG:
> Yes, this is a mess, introduced long before I was
> involved in groff. However, this affects the ter-
> minology but not the documentation itself. AFAIK,
> I've fixed all places in the doc files to make a
> clear distinction between input characters and
> output glyphs.
>> However, please avoid the term 'AGL compatible'. We are not
>> talking about glyphs but about characters!
>
> Maybe this confusion is not only my fault also the manual's:
>
> The distinction between input, characters, and output, glyphs,
> is not clearly separated in the terminology of
Thank you for the kind and patient explanation,
Werner.
> However, please avoid the term 'AGL compatible'.
> We are not talking about glyphs but about charac-
> ters!
Maybe this confusion is not only my fault also the
manual's:
The distinction between input, characters,
and o
> Ah, thank you. So you are mapping the Russian alphabet to internal
> characters corresponding to KOI-8-R and then using a hyphenation
> pattern in the same encoding.
Yes.
> This way, not only UTF-8 input may be fed to groff, but also KOI-8-R
> -- just omit preconv processing (the -K or -k opti
Sorry for the mangled text in the previous message.
Werner LEMBERG:
> I've posted a solution a few years ago to the
> groff list which is still valid.
Ah, thank you. So you are mapping the Russian alpha-
bet to internal characters correspoinding to KOI-8-R
and then using a hyphenation patt
Werner LEMBERG:
> I've posted a solution a few years ago to the
> groff list which is still valid.
Ah, thank you. So you are mapping the Russian alpha-
bet to internal characters correspoinding to KOI-8-R
and then using hyphenation patterns in the same
encoding.
This way, not only UTF
> I ran my file through preconv and the result contained
> algorithmically derived glyphs \[u] for Russian letters, which,
> by definition, are not part of the GGL.
Sorry for being sloppy. \[u] is what groff expects for all glyphs
not part of the GGL.
> But what to do with hyphenation?
Werner LEMBERG:
> Please don't hesitate to ask! Ideally, you could
> then improve the documentation based on your ques-
> tions :-)
Thanks, I appreciate it. I thouhgt I'd jot a draft
document descirbing various aspects of setting up
groff for a specific language, that would include
deal
> I got the font working, although I do not completely understand what
> is going on internally.
Please don't hesitate to ask! Ideally, you could then improve the
documentation based on your questions :-)
> In addition, the CMCyr package, which I registered with Groff, is
> only an extension to
Hello, Werner, and thank you for the reply.
I got the font working, although I do not completely
understand what is going on internally. In addition,
the CMCyr package, which I registered with Groff, is
only an extension to the Computer Modern fonts hav-
ing only Russian-specific symbols, and i
> I want to use Russian KOI8-encoded Type 1 fonts with Groff.
> Provided that I am using UTF-8-encoded Groff sourcres, does it mean
> that I should create my own font_map file in order to specify the
> translation from Groff internal characters, used in the UTF-8 mode,
> into PostScript character
Hello, all
I want to use Russian KOI8-encoded Type 1 fonts with
Groff. Provided that I am using UTF-8-encoded Groff
sourcres, does it mean that I should create my own
font_map file in order to specify the translation
from Groff internal characters, used in the UTF-8
mode, into PostScript
22 matches
Mail list logo
