> In order to work, you need compile plucker with --enable-unicode
> and with --disable-imode. For backward compatibility, only UNICODE
If this code makes it into Plucker, we can probably drop the current
implementation of imode and instead support imode with custom fonts that
include the imode i
Hi
this patch adds supoprt for arbitrary unicode values for
plucked characters for antialiased fonts. I tried to keep the
changes to code to be minimal, as well as to preserve backward compatibility,
therefore this patch is centered about using UNICODE tokens
via utf-8, which fits nicely into Palm
> > How do we mishandle shift-jis? We just use the OS's multibyte
functions,
> > and we assume that a CJK-OS traps the OS's multibyte char access
functions.
> >
>
> in paragraph.c, line 1564, there is some conversion going on (seems like
> parser puts raw SHIFT_JIS characters into the file, but cl
> > Or, more simply, we could just use the current inefficient Unicode
support
> > (via the UNICODE16 and UNICODE32 functions in the Plucker doc format),
and
> > hook it up with the grayscale fonts and a map specifying ranges, and
just
> > ensure that the parser uses it more aggressively.
>
> yes,
On Thu, Feb 12, 2004 at 10:21:25AM -0500, Alexander R. Pruss wrote:
> > Yes, but multibyte text storage (and btw the one in plucker is crippled
> and
> > won't be usable because of SHIFT-JIS (mis)handling
>
> How do we mishandle shift-jis? We just use the OS's multibyte functions,
> and we assume
> Yes, but multibyte text storage (and btw the one in plucker is crippled
and
> won't be usable because of SHIFT-JIS (mis)handling
How do we mishandle shift-jis? We just use the OS's multibyte functions,
and we assume that a CJK-OS traps the OS's multibyte char access functions.
> Besides, grays
Just to clarify what I had in mind - I was not speaking about "full"
unicode support (whatever you mean by "full"), but rather about UCS2
without BIDI and combining characters - i.e. support that is already
in plucker, but is not used because of some missing implementation
details. And it is all a
On Wed, 11 Feb 2004, Radovan Garabik wrote:
> I know, but that does not solve the original problem - if the page
> I want to pluck uses e.g. iso-8859-2 repertoire and it has a link to page that
> uses iso-8859-1 (or koi8-r or anything, or even worse, characters from more
> codepages). As I said, su
On Mon, Feb 09, 2004 at 10:09:17AM -0500, Alexander R. Pruss wrote:
> > yes, it works, but that was what I meant by an "ugly hack", and it does
> > not solve the situation if you are making plucker document out of
> > www site that uses different encodings.
>
> jPluck will convert between encoding
> yes, it works, but that was what I meant by an "ugly hack", and it does
> not solve the situation if you are making plucker document out of
> www site that uses different encodings.
jPluck will convert between encodings.
> Besides, I did not found any
> ISO-8859-2 fonts (I think I am going to m
On Mon, Feb 09, 2004 at 09:12:26AM -0500, Alexander R. Pruss wrote:
> On Mon, 9 Feb 2004, Radovan Garabik wrote:
> > What do you think about extending plucker to handle unicode better?
> > (i.e. making it usable for ISO-8859-2 people, since for them
> > plucker does not work at all)?
>
> Sorry for
On Mon, 9 Feb 2004, Radovan Garabik wrote:
> What do you think about extending plucker to handle unicode better?
> (i.e. making it usable for ISO-8859-2 people, since for them
> plucker does not work at all)?
Sorry for my naivete, but isn't it just a matter of dropping in an
ISO-8859-2 font, and u
(this is a repost - if you see the mail twice, please ignore it)
Hello
Week or two ago I obtained my palm (tungsten C), and so I started
playing with it. Plucker is an excellent piece of software, but
its lack of i18n abilities is a stopper for anyone willing to
use it outside of ISO-8859-1 range
13 matches
Mail list logo
