> 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, grayscale font renderer already does support unicode (UCS2), For a contiguous range. > so > eventual OS support is irrelevant (if you are using grayscale fonts, not > the system ones) > Anyway, even if some future OS makes some sort of unicode support, > 1) users of older devices are not going to flash their ROMs en mass > 2) grayscale fonts have still nothing to do with OS, so they would > need this implementation (what I am talking about) anyway I would hope that a future OS would include subpixel-rendered Unicode TTF, but one can only hope. > > The number of users who need to pluck sites that use multiple code pages > > in ways that matter. For most English pages, for instance, it is no > > disaster if you pretend the page is in some other encoding--at most a few > > characters will be mixed up--and one expects that most, though not all, > > multilanguage plucks are going to be Some Other Language plus English, > > rather than two non-English languages. > > I agree. However, it renders plucker unusable for me :-) Fair enough. > > So I am not sure that it is worth > > supporting this. It may slow down rendering. It will make maintenance > > more work for all the developers. > > Note that rendering is already unicode (UCS2). UTF-8 implementation > would slow just text parsing (but UTF-8 parser is something like > 6 lines of C code consisting of bitshift and AND operations) 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. Anyway, some time ago, I posted something suggesting how one might extend the gray-scale font format to allow for Unicode mapping and non-contiguous ranges. If you search for "Unicode" you can find it. As a preliminary to adding it to Plucker, you are free to add support for that suggested method of doing things to togray.c, topalmtext.c, and toplucker.tcl in the PalmFontConv package. You will also need to add to toplucker.tcl some way of selecting multiple Unicode ranges to include in a font, since a bitmap of all of, say, MS's Times New Roman would be way too large. You can also make any needed changes to the grayscale routines in Plucker, and I'll include them in PalmFontConv as the sample renderer. By then, the feature freeze on Plucker might be over, and we can negotiate about implementing this in Plucker, I guess. I am not that averse to it. In any case, the feature will have become available to anybody else using the PalmFontConv grayscale routines, e.g., PalmBible+ (where the need for Unicode ahs come up). Alex _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
