What'd be nice is a small program that would automatically find and
replace the codes with the characters. That'd lose things like left
and right quotes, but on a small PDA screen it makes little
difference. For characters with no direct equivalent, like the
lozenge, the program could allow t
On Fri, Jun 16, 2006 at 10:24:31PM -0700, Gregg Eshelman wrote:
> Is there an easy way to replace Unicode characters
> in HTML with their ASCII/ANSI equivalents?
> A Unicode character in an HTML file is coded like
> #&0028;parenthetical statement#&0029;
> In ASCII/ANS
Is there an easy way to replace Unicode characters
in HTML with their ASCII/ANSI equivalents?
A Unicode character in an HTML file is coded like
#&0028;parenthetical statement#&0029;
In ASCII/ANSI it's
(parenthetical statement)
Does the Plucker converter grok Unicode?
What&#
On Tue, Apr 11, 2006 at 01:18:59PM -0700, Jeremy Brown wrote:
[...]
> 3. Do codes already exist in the Plucker file format to say,
> "this page is stored as UTF8 / UCS-16 / KOI8-R / ISO-8859-6 /
> etc."? Or would this be something that might need to be
> decided on and included?
PyPlucker has exc
What kind of changes need to be made to tie in the Unicode library:
1. What changes in the C code for Palm? (Which c files handle reading the
text from database, displaying the text, etc.)
2. What changes in the Python distiller? (What files would need changes -
what kinds of changes)
3. Do
1:58 AM
To: plucker-dev@rubberchicken.org
Subject: Re: Unicode library
On Fri, Apr 07, 2006, Gregg Eshelman wrote:
> How about a unicode to ASCII/ANSI translation table?
The problem is more about "who" will do it than "how" to do it ;-)
/Mike
__
On Fri, Apr 07, 2006, Gregg Eshelman wrote:
> How about a unicode to ASCII/ANSI translation table?
The problem is more about "who" will do it than "how" to do it ;-)
/Mike
___
plucker-dev mailing list
plucker-dev
--- Michael Nordstrom <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2006, Mullins, Steven wrote:
> > Jeremy Brown has written an opensource unicode
> library for palm.
>
> Looks interesting. I will take a closer look at it
> this weekend. The
> only thing I'
On Mon, Apr 03, 2006, Mullins, Steven wrote:
> Jeremy Brown has written an opensource unicode library for palm.
Looks interesting. I will take a closer look at it this weekend. The
only thing I'm "worried" about is that it would require major changes
to the python parser to i
Jeremy Brown ([EMAIL PROTECTED]) has written an opensource unicode library for
palm (http://unbound.biola.edu/unibible/using_unicode.cfm). He let me know
that he would be happy to help develop Plucker to use the library, if the
developers would like. I for one would like to see Unicode
David A. Desrosiers wrote:
This is plucker & palmfontconv unicode patch.
List of relevant changes:
Just curious if this has been implemented yet.
No. I never got around to merging the code into PalmFontConv...
Alex
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown Univer
> This is plucker & palmfontconv unicode patch.
> List of relevant changes:
Just curious if this has been implemented yet. The thread
seemed to die here, and its 9 months old. I have a few pages that look
pretty bad without proper utf-8 support in Plucker.
I tried t
Radovan: This looks very good! I think I'll implement the PalmFontConv
patch soon. Alex
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133 U.S.A.
e-mail: [EMAIL PROTECTED]
online papers and home page: www.georgetown.edu/faculty/ap85
--
This is a comparision between original plucker, and
plucker with unicode patch. The number measure time
(in ticks) needed to draw paragraph (DrawParagraph in
paragraph.c). The test consisted of displaying
pure ASCII document and scrolling first ten pages,
repeated three times (thus the three
This is plucker & palmfontconv unicode patch.
List of relevant changes:
Palmfontconv:
topalmtext has parameter -r used to select ranges of unicode characters to
include. Use it like this:
topalmtext -r-017f:0400-04f9:2010-2030 ...
to select Latin1, Latin-A, Cyrillic and some use
> > Do you need to turn off uses8BitChars for unicode documents that do
unicode
> > via the UNICODE16 and UNICODE32 functions, rather than for UTF-8
documents
> > (which I assume are flagged in some way)?
>
> yes, because currently UTF-8 files are not supported at all
>
On Thu, Mar 18, 2004 at 08:37:08AM -0500, Alexander R. Pruss wrote:
> >
> > But how are you going to say in advance that document uses unicode
> > characters, without parsing it all?
>
> Do you need to turn off uses8BitChars for unicode documents that do unicode
> via
> We than declare that GrayFontGlyphInfo[] contains glyphs in ascending
> order, but with skipping permitted. First min(255, lastChar-firstChar)
> glyphs has to be continuous, without skipping - this makes new fonts
> compatible with older plucker, and older fonts will be usable with
> new plucker
From: "Radovan Garabik" <[EMAIL PROTECTED]>
> I have no data, but I am using unicode plucker daily, and I do not
> perceive any speed difference between original plucker and patched one
You could insert some timer calls, and test two things:
(1) the amount of time to r
On Wed, Mar 17, 2004 at 11:58:25AM -0500, Alexander R. Pruss wrote:
> Do you have performance data? Is rendering slowed down for non-Unicode
> text?
I have no data, but I am using unicode plucker daily, and I do not
perceive any speed difference between original plucker and patched one
(
This is patch for palmfontconv
first, non unicode related changes:
- fixed compilation on ELF systems
- fixed myalloc(0) problem in togray.c with big fonts (test if InResource is zero)
- topalmtext.c now skips characters not present in source fonts
this makes resulting fonts somewhat smaller
I'm looking at the patch. It would be great to have this sort of thing in
Plucker if it can be made to work. Two questions/comments:
1. I think you should NOT turn off uses8BitChars unless the document
actually uses Unicode. In 8-bit mode, searching is much faster (several
times faster
Do you have performance data? Is rendering slowed down for non-Unicode
text?
Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
On Sat, Mar 13, 2004 at 08:15:43PM -0500, Alexander R. Pruss wrote:
> > you can select anything as --output-charset, characters from
> > --input-charset that cannot be represented in --output-charset
> > are included as unicode values - this is why default --output-charset
&g
On Thu, Mar 11, 2004, Radovan Garabik wrote:
> New version of plucker unicode patch.
It is great that you add support for this, but in what way is this
related to the libraryform enhancements? Please don't use a message
from a completely different thread as a "template". Usual
> 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
> > It would actually be pretty easy. PalmBible+ reads both Plucker and
> > PalmBible+ font packages right now. Shall I implement it?
>
> Definately!
Actually, it's harder. One would have to convert afnx->nfnt on the fly. I
don't feel like doing that.
Alex
___
> Unicode Greek? Or you mean, GreekKeys Greek?
Oh, bummer. The Plucker document I was playing with was the Pluckerbooks
Greek New Testament, which has a transliteration as the alternate
representation for unicode characters. In messing with fonthack, the
GreekKeys font was rendering
On Fri, 5 Mar 2004, Dave Maddock wrote:
> I don't know why I didn't play with fonthack before, but Plucker
> renders unicode greek nicely as is with fonthack and the fonts from
> PalmBible+. (sweet program btw, Alex).
Unicode Greek? Or you mean, GreekKeys Greek? (I have a P
I don't know why I didn't play with fonthack
before, but Plucker renders unicode greek nicely as is with fonthack and the
fonts from PalmBible+. (sweet program btw, Alex).
http://dave.maddockfamily.org:81/fonthack.png
palmfontconv supports grayscale font creation for
plucker an
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
IFT_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.
Yup, that's intentional. :-) According to NTT Docomo "S-JIS character
encoding must be used" on i-mode
> > 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 mo
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
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)
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
de
). As I said, support in plucker is _almost_ there and I am willing
> to work on it - but only if there is an interest in developpers' comunity
> to include the support in plucker.
One concern is that if we roll our own solution for this, then along may
come a future OS version with nati
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 wor
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-88
glyphs, but e.g. for latin1+latin2, or latin1+latin2+ipa or
latin1+latin2+ipa+ greek or latin1+latin2+greek+ipa+cyrillic
fonts it is perfectly suitable.
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
space if I wanted to make a font to
support just Greek (880-1023) and Extended Greek (7936-8191).
> extend things with a binary search for non-sequential glyphs. But the
> speed may be too low. (A best solution for occasional Unicode might be to
> require sequential numbers with no skips in
On Fri, 15 Aug 2003, Dave Maddock wrote:
> Since I've been playing with the unicode functions in the parser and
> viewer, I think I may have a viable idea for displaying unicode
> characters. This is kind of how my i-mode patch works (only using
> bitmaps instead of fonts of cour
Since I've been playing with the unicode functions
in the parser and viewer, I think I may have a viable idea for displaying
unicode characters. This is kind of how my i-mode patch works (only using
bitmaps instead of fonts of course).
The big problem is that PalmOS doesn'
I was looking, rather, for pdbs that use the UNICODE16 and UNICODE32
functions. I don't know how unicode fonts would work on the Palm. Sorry!
Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/pl
Hi, I'm new to the list. I'm looking into ways to
improve reading Big5 Chinese on plucker. From the
archive Alexander R. Pruss wrote on 6-July that he
needs a unicode pdb to test it out. I have uploaded
some of them to my web site.
pdb in Chinese Big5, 824 bytes
http://home.graffiti
> What is multibyte support about then? I found a reference to this in the
> archives, but it seems this is available in the I18N branch only.
> Unfortunately I still can't reach www.plkr.org or cvs.plkr.org to check
> this out.
Multibyte support is for devices, e.g., Japanese ones (I think these
On Tue, 8 Jul 2003, JPluck wrote:
> OK, that clears things up. So my conclusion is correct: the Viewer
> currently only handles 8-bit encodings and ignores character set records
> in the metadata section. The character encoding in the document must
> match the encoding set on the device in order
It doesn't. The distiller tries to detect and communicate the encodings
of particular parts, but given the abysmal PalmOS support for charsets
and the non-existent Python 1.5.2 support, we can't do much with it.
If we move to Python 2.x, we can manage the charsets, but what to do
about the poor Pa
> Anyway, I tried writing out text using UTF-8 and UTF-16 and the
> documents all came out wrong in the Viewer. Actually I don't understand
> how the Viewer handles different character encodings(if it does at all).
> It displays different 8-bit encodings (Big-5, ISO-8859-2, KOI8-R) fine,
> as l
There are two unicode functions, UNICODE16 and UNICODE32 implemented in
paragraph.c. Since I've made a lot of changes to paragraph.c (fixing
sub/superscript code, and speeding up rendering a lot), I thought it
woould be nice to check if they still work. Alex
On Mon, 7 Jul 2003, JPluck
I need a document, ideally a .pdb, that I can test Plucker's unicode
handling on. Does anyone have such a document? Alex
This is news to me. Since when does the Viewer support Unicode?
The Plucker spec says that text data records contain a stream of ISO
Latin-1 characters. This is
I need a document, ideally a .pdb, that I can test Plucker's unicode
handling on. Does anyone have such a document? Alex
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133 U.S.A.
e-mail: [EMAIL PROTECTED]
online papers and home
On Wed, Oct 02, 2002, Laurens M. Fridael wrote:
> - Encryption using the owner_id does not yet work in the Viewer, right?
After a bug fix by Bill the owner ID stuff works again (it wouldn't
work for some user IDs and one of them turned out to be mine:)
> - Is there any feature supported by the V
> - Encryption using the owner_id does not yet work in the Viewer, right?
It worked on the viewer a couple of months ago...
Bill
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Hi,
I have implemented nearly all features from the Plucker format specification
in my Java library. Three more questions:
- Are Unicode sections in text records supported by the Viewer? If so, is it
possible to test this on an English version of Palm OS (which, presumably,
only has ISO-8859-1
On Tue, Nov 20, 2001, Bill Janssen wrote:
> When a non-Latin-1 (non-ASCII?) character is encountered, add a
> function code which describes two things: the numeric character code,
> and the length of an alternative Latin-1 (ASCII?) string (like "-" for
> en-dash, or "--" for em-dash). This would
The fact that HTML is full Unicode is a bit disconcerting. I'd like
to support that in the DB format, and eventually in the viewer as
well. But at the same time I'd like to keep the text display fairly
simple so that the Latin-1 Palms can handle it.
Right now the TextParser looks
59 matches
Mail list logo
