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 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 claiming they are UCS2 - or is it vice versa?). This will IMHO mess up with unicode values, if plucker is compiled with HAVE_IMODE. > > 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. > yes, that could be a first step - after all, in latin-based languages, it would increase the text size just by a few percent. -- ----------------------------------------------------------- | Radovan Garabík http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__ garabik @ melkor.dnp.fmph.uniba.sk | ----------------------------------------------------------- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
