On Tue, 31 Oct 2000, Martin Sevior wrote:
>
> On Tue, 31 Oct 2000, Vlad Harchev wrote:
>
> >
> > No, 'char' is treated as 'signed char' per ANSI C standard. So (unsigned
> > char) cast was necessary.
>
> Thanks for the clue. The high order bit was propagated into the second
> byte.
>
> >
> > > I've applied the patch to a new tree merged with Dom's new gnome-print.
> > > It compiles and builds without problems on RH 6.2 in unix. I haven't
> > > tried a gnome build yet coz I gotta get the latest gnome-print. Now the
> > > Lists dialog and the symbols inserted into frame look correct but printing
> > > the symbols doesn't work. I get some strange symbol instead. When I used
> > > "Insert Symbol" to insert "Dingbats" fonts into the text they appeared OK
> > > on the screen but upon printing looking like Chinese characters.
> > >
> > > The old abi did this too.
> >
> > OK, I'll look into it and it seems it would be easy to fix it.
> > measureUnremappedChar is guilty.
> > But did this problem exist between my non-latin1 support patch?
> >
>
> Yes it did. I should have told you sooner but you seemed to have enough
> other things to do.
I assume you did s/between/before/ when answering my question? If not,
please tell whether this problem was before (not "between") my first
non-latin1 support patch.
> Also your next-cjk.patch slipped in another call to
> iconv( blah, (const **)&inptr,....
>
> gcc 2.96.* with RH 7.0 does not like this. You need
>
> iconv(blah, const_cast<char **>(&inptr),...
OK, thanks.
> Cheers
>
> Martin
>
Best regards,
-Vlad
