if libicons works while iconv() produces wrong results would it be the
better way to use libiconv in general ? (until iconv() problems are fixed ?)
just my 2 cents,
walter
Bruno Haible wrote:
Alexander E. Patrakov wrote:
The answer "patch
glibc so that iconv transliterates the bullet to '
Bruno Haible wrote:
Alexander E. Patrakov wrote:
The answer "patch
glibc so that iconv transliterates the bullet to 'o'" is better (and in
fact this is doable), but I think that users of non-Glibc systems (or
old Glibc) will complain if this becomes the official answer.
Why should the
walter harms wrote:
if libiconv works while iconv() produces wrong results would it be the
better way to use libiconv in general ? (until iconv() problems are
fixed ?)
No, for the following reasons:
1) because iconv() from libiconv, unlike iconv() from Glibc, totally
ignores locale-specific
I wrote:
Is this patch a right solution?
Forgot to say: even if it is, it would be insane to require patched or
not-yet-released version of glibc just for viewing manual pages "the
right way" in locales such as pl_PL. A short-term distro-friendly
solution is also needed. Any ideas?
--
Ale
Alexander E. Patrakov wrote:
> because of the unknown interaction between libiconv and glibc. I
> tested libiconv by installing in into /opt/libiconv. I heard that users
> screwed up their systems by installing libiconv into /usr, and thus I
> won't do this myself. Clarification is needed from the
Alexander E. Patrakov wrote:
> >Why should they complain? They can use GNU libiconv. It transliterates the
> >bullet to 'o', like you wish.
>
> The "iconv" program from libiconv transliterates the bullet to ".",
> which is also acceptable.
libiconv converts the MIDDLE DOT to '.' and the BULLET and
> For the first step, the support of all Unicode characters without
> huge data tables, I intend to submit modifications to the following
> files:
Thanks!
While I fully agree that groff's source code files should have much
more comments, I'm not really happy with the layout you provide in
your p
Hello Werner,
> While I fully agree that groff's source code files should have much
> more comments, I'm not really happy with the layout you provide in
> your patch. James Clark's code has a certain compactness which I
> would like to retain
Personal preferences about style obviously differ. Th
Bruno Haible wrote:
As for the "iconv" program from glibc, the situation is worse. I have
prepared a patch against Glibc-2.3.6 (attached) that transliterates the
offending characters produced by Groff into their ASCII equivalents if
there is no any other suitable fallback. You can try it without
super
say
hear
can
cancel
forget
Be
send
clean
To
spell
need
The
sit
go
him
break
use
In
fall
wait
was
think
do
true
sing
take
me
believe
take
active
know
play
___
Bug-groff mailing list
Bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gr
Alexander E. Patrakov wrote:
> >The ACUTE ACCENT part looks wrong.
>
> But libiconv also transliterates it to "'" :)
The correctness criteria for glibc are stronger than for libiconv, since
it's used by many more people.
It can also be a bug in libiconv, due to the fact that at the time when
I in
> > 1. An acute accent is not a quoting character. Anyone using an
> > acute accent for quoting is abusing this character.
>
> Agreed, Groff should be fixed. Also it probably should use Unicode
> bullets (not middle dots) for bullets.
I won't change the defaults. From the PROBLEMS file:
*
> So: what is the official recommendation upon formatting manual pages
> in non-ISO-8859-1 non-UTF-8 locales with the CVS version of Groff?
You might provide small locale-specific macro files loaded in addition
to -man which translate the problematic characters to something iconv
can digest correc
> > While I fully agree that groff's source code files should have
> > much more comments, I'm not really happy with the layout you
> > provide in your patch. James Clark's code has a certain
> > compactness which I would like to retain
>
> Personal preferences about style obviously differ. Thank
> > classes
> > = A :A 'A `A ... ;
> > = U+3000 - U+303F;
> > = U+3040 - U+309F;
> > ...
> >
> > = ... ;
> >
> > properties
> > width 24
> > ...
> > kern V -3
>
> I see. I had imagined the same thing with just the properties and
> no classes, like the PO
Hello Werner,
Thanks for all the answers.
> > economic both in space in the font file format and in memory, rather
> > than a representation that enumerates character after character.
>
> This is what I mean with `classes', something like this in a font
> description file, using two new sections:
16 matches
Mail list logo
