Hi Ralph,
> Post the URL to the list when it's done; will help someone reading the
> list archives in the future.
The issue report can be found in
https://savannah.gnu.org/bugs/index.php?42870
> You could use .pso to read in an `iconv -t iso-8859-1' of your
> UTF-8-encoded file. :-)
That's a
Hi Carsten,
> Ok, I'll do that.
Post the URL to the list when it's done; will help someone reading the
list archives in the future.
> > PS: A clean solution currently is to put `.hw' lines into a separate
> > file that uses the proper 8bit encoding, and that file gets then
> > included with `.s
> No, it's not a bug in preconv, it's a bug in troff: `.hcode' and `.hw'
> are limited to raw 8bit characters. Instead, they should accept any
> characters entities like `\[u00AD]'. Similarly, `.hpfcode' should be
> modified to allow entities, too.
I agree! That really would be the best solution
> No, it looks like you're right. `info groff' says
>
> -- Request: .hcode c1 code1 [c2 code2 ...]
>
> Set the hyphenation code of character C1 to CODE1, that of C2 to
> CODE2, etc. A hyphenation code must be a single input character
> (not a special character) other than a digi
Hi Carsten,
> Now the error message is "hyphenation code must be ordinary
> character". So I understand that the only correct file enocding for
> .hcode with umlauts is latin1 (ISO 8859-1)? Or is there any chance to
> use 7-bit input like \[u]?
>
> $ printf ".hcode ä ä"|preconv -e utf-8|troff
Again the example had been missing:
$ printf ".hcode ä ä"|preconv -e utf-8|troff
Prints error "hyphenation code must be ordinary character"
> Please provide an actual example input and command line that lets us
> reproduce your error.
Sorry, you are right, I should have been providing an example! By creating that
I saw that there has been an error in my makefile...
Now the error message is "hyphenation code must be ordinary characte
Hi Carsten,
> I put "preconv -e utf-8 | pic | ..." in front of the
> pipe and it does not seem to work (I prefer the pipe instead of
> groff(1)). It converts "ä" to "\[u00E4]" but pic(1) also complaines
> with "invalid input character code".
Works for me.
$ printf %s\\n .PS 'box "hello ä"'
Hi Ralph,
> > Is utf8 input not supported?
>
> It is not. Not directly, anyway.
(In general I like to use 7-bit input anyway.)
So I understand it is best to have a latin1 (ISO 8859-1) coded input file for
.hcode with umlauts?
> Groff supports various single-byte encodings for input; see `In
Hi Carsten,
> I have used a .hcode request with german umlauts like
>
> .hcode ä ä
>
> and so on. That had been working some time ago. Maybe I've made the
> mistake now to save that file as utf8. Now I get error messages like
>
> invalide input character code 132
>
> and so on (from
Hello,
I have used a .hcode request with german umlauts like
.hcode ä ä
and so on. That had been working some time ago. Maybe I've made the mistake
now to save that file as utf8. Now I get error messages like
invalide input character code 132
and so on (from pic(1), which is the fi
11 matches
Mail list logo
