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
Alan Hoyle [EMAIL PROTECTED] wrote:
take http://nelson.oit.unc.edu/~alanh/tmp/plucker-feature-matrix.html to
use on their site, I've added a Creative Commons license to it. Or would
You are discriminating against commercial use, so I think this licence
is not very nice. Plucker can be used
Well, if I am not mistaken, it's all in HEAD in CVS now, so as soon as the
daily snapshot make is fixed, it will be available daily on plkr.org, no?
I managed to solve the bug in the Makefile regarding the fontconv
issue, but there's still an open issue prohibiting the hourly snapshots
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
On Mon, 7 Jul 2003 at 21:49, Chris Pepper wrote:
The chart says AG doesn't do compression, but
http://www.plkr.org/index.plkr?a=faqsec=1.2 says:
AvantGo parses compressed (i.e. encrypted) html on the Palm device
itself; Plucker parses uncompressed html on the server, and sends an
I am trying to optimize the rendering code. Things could, indeed, be made
more efficient if one didn't care about multi-byte encodings. Of course,
we should care about them. ANyway, while optimizing, I had some
questions:
1. There is no guarantee that every bit of text in a record is followed
Here's a puzzle about paragraph.c/GetLineMetrics(). The puzzling code
reads:
/* CRLF can be inserted anywhere if it is multibyte char */
if ( TxtGlueCharSize( nextToken ) == 2 ) {
lastSpacePixels = linePixels;
lastSpace = tokenCount;
One of my recent optimizations involved using FntWordWrap() for some of
the rendering. But now I have a worry. Maybe FntWordWrap() can't handle
soft hyphens? Does anyone know?
Also, does anyone know what FntCharsWidth() returns if there is a soft
hyphen in the string?
Alex
--
Dr. Alexander
On Tue, Jul 08, 2003 at 11:00:26AM -0400, Alexander R. Pruss wrote:
1. There is no guarantee that every bit of text in a record is followed
eventually by a null, right? (There is, e.g., no guarantee that there is
a function at the end of a record, or a terminating null?)
I don't think so. If
The Plucker soft hyphen character 0xA5 maps to a yen character on the Palm
side. Does this mean that Plucker can't handle documents with a yen
character?
I propose that we make the soft hyphen character into a function rather
than an actual character, and remove support for 0xA5 as a soft
On Tue, Jul 08, 2003 at 11:04:27AM -0400, Alexander R. Pruss wrote:
1. This looks to me like it's checking for all two-byte length characters,
not just CRLF. This surely isn't correct behavior, because it will allow
line-breaking at any two-byte length character.
I think you're right...
2.
On Tue, 8 Jul 2003, Adam McDaniel wrote:
3. And why should there be a CRLF in the record given that we have
function 0x38 instead?
Why would there be a CRLF in html if there's a br/p tag instead?
For human readability. But I had assumed, I guess wrongly, that all such
things get stripped
Nevermind. I have a horrible memory for numbers--I misremembered the
0x00AD as a 0x00A5.
While on the subject of soft hyphens, no FntWordWrap() does not handle
them. However, it doesn't really matter given how I use FntWordWrap().
(I back up from the break indicated by FntWordWrap() one
As Chris Pepper said, I don't want to fork the chart.
I would be willing to maintain it, if it could be hosted
at (or at least linked from) plkr.org directly, so that
people can find it.
Eventually, I would like to include more comparisons,
such as what you might get with a Doc Reader or an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As Chris Pepper said, I don't want to fork the chart. I would be willing
to maintain it, if it could be hosted at (or at least linked from)
plkr.org directly, so that people can find it.
Feel free to make a final copy, and draft up a few
Hi, I have a Clie SJ20 which supports HiRes 16 grayscale. However, the default
HiRes mode is BW. One needs to explicitly set the screen depth to 4 in order
to get HiRes 16 grayscale. I hope the following code from Vexed source can
help:
Errerr;
UInt16 cBpp;
UInt32 dwVer;
UInt32 dwDepth
Using the general prefs settings to change to depth 4 doesn't work? 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
2. Can multi-byte encoded texts have nulls that do not signal the end of
the string, i.e., nulls in the middle of multi-byte characters? (I
assume
there can't be nulls at the start of them--if there can, our code is in
trouble.)
Uhmm.. although this isn't my area of expertise, but I
Also, does the 1.2 Hires version support Virtual graffiti
(either handera or Sony) or not?
Where would they get a binary for 1.2 Hires? I'm not sure
exactly when this got in, but I think all the binaries currently
on hires.plkr.org do.
Note: if this feature matters to you, you may wish
On Tue, 8 Jul 2003 at 13:48, Jewett, Jim J wrote:
Also, does the 1.2 Hires version support Virtual graffiti
(either handera or Sony) or not?
Where would they get a binary for 1.2 Hires? I'm not sure
exactly when this got in, but I think all the binaries currently
on hires.plkr.org do.
Alexander R. Pruss
Here's a puzzle about paragraph.c/GetLineMetrics(). The
puzzling code reads:
/* CRLF can be inserted anywhere if it is multibyte char */
if ( TxtGlueCharSize( nextToken ) == 2 ) { ...}
1. This looks to me like it's checking for all two-byte
length
David, I added some more stuff to a clone of your feature matrix:
http://nelson.oit.unc.edu/~alanh/tmp/a-vs-p-vs-i.html
Most notably: footnotes giving details for some of the comparisons.
On Tue, 8 Jul 2003 at 12:42, David A. Desrosiers wrote:
Date: Tue, 8 Jul 2003 12:42:24 -0400 (EDT)
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
1. This looks to me like it's checking for all two-byte length characters,
not just CRLF. This surely isn't correct behavior, because it will allow
line-breaking at any two-byte length character.
Well, I think you are making a mistake in your
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
Nevermind. I have a horrible memory for numbers--I misremembered the
0x00AD as a 0x00A5.
I think we should mind anyway. Bug report #356 is a related problem
for 0xAD and the Thai language.
/Mike
___
On Tue, 8 Jul 2003, Michael Nordstrom wrote:
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
1. This looks to me like it's checking for all two-byte length characters,
not just CRLF. This surely isn't correct behavior, because it will allow
line-breaking at any two-byte length character.
On Tue, 8 Jul 2003, Michael Nordstrom wrote:
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
Nevermind. I have a horrible memory for numbers--I misremembered the
0x00AD as a 0x00A5.
I think we should mind anyway. Bug report #356 is a related problem
for 0xAD and the Thai language.
We
On Tue, Jul 08, 2003 at 11:44:59AM -0400, Alexander R. Pruss wrote:
That still leaves one question. Does the OS encode CRLF into a WChar as
0x0D0A or as 0x0A0D? (These endian things are confusing.) Or as
something else?
I would highly doubt that. I would suspect that a CRLF would be
On Tue, Jul 08, 2003 at 01:52:23PM -0400, Alan Hoyle wrote:
Where would they get a binary for 1.2 Hires? I'm not sure
exactly when this got in, but I think all the binaries currently
on hires.plkr.org do.
http://hires.plkr.org/download/prc/old/
1.2beta13-hires-1 is the latest one.
I was
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
I am also a bit puzzled as to why the special handling for
two-byte characters? (Why not three- or four-byte ones?)
Because that's what Matto implemented... If you want to see something
else then you know the drill ;-)
/Mike
On Tue, Jul 08, 2003 at 01:34:30PM -0500, Nguyen The Toan wrote:
On Tuesday July 8 2003 12:44 pm, Alexander R. Pruss wrote:
Using the general prefs settings to change to depth 4 doesn't work? Alex
Yes, it does. I miss it the first time.
When you run the viewer for the first time, it
On Tue, 8 Jul 2003, Michael Nordstrom wrote:
On Tue, Jul 08, 2003, Alexander R. Pruss wrote:
I am also a bit puzzled as to why the special handling for
two-byte characters? (Why not three- or four-byte ones?)
Because that's what Matto implemented... If you want to see something
else then
At 1:54 PM -0600 2003/07/08, Adam McDaniel wrote:
On Tue, Jul 08, 2003 at 01:34:30PM -0500, Nguyen The Toan wrote:
On Tuesday July 8 2003 12:44 pm, Alexander R. Pruss wrote:
Using the general prefs settings to change to depth 4 doesn't work? Alex
Yes, it does. I miss it the first time.
When
Is there anywhere one can ask to get an official answer to such a
question, as my question whether middle or final bytes can be zero?
--
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:
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 are
I propose that we make the soft hyphen character into a function rather
than an actual character, and remove support for 0xA5 as a soft
hyphen. Or am I misunderstanding something in the code?
The current code mainly just tries to pass bytes along, so that it
will work for various character
Why would there be a CRLF in html if there's a br/p tag instead?
For human readability. But I had assumed, I guess wrongly, that all such
things get stripped out by the distiller.
Or because you're in a PRE region.
Bill
___
plucker-dev mailing
It depends on the multibyte encoding. However, in Plucker, we really
can't have them, since we use NUL to introduce function codes in the
text stream. I think you can count on this for text records in a
Plucker DB.
Bill
2. Can multi-byte encoded texts have nulls that do not signal the end
On Tue, 8 Jul 2003, Bill Janssen wrote:
So there is no support for 0xA5 in the code (and nothing to remove);
This is true for 0xA5. But it's not true for 0xAD. Support for the
soft-hyphen is hardcoded in.
Alex
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department ||
On Tue, 8 Jul 2003, Bill Janssen wrote:
It depends on the multibyte encoding. However, in Plucker, we really
can't have them, since we use NUL to introduce function codes in the
text stream.
The present code will work fine with NUL in the middle of a multi-byte
character. Only a NUL at the
On Tue, Jul 08, 2003, Chris Pepper wrote:
Should Plucker choose the highest available, rather than the
system default?
Nope. The text rendering is faster at the default bit depth, so
that's what we should start with.
/Mike
___
plucker-dev mailing
On Tue, Jul 08, 2003 at 04:13:16PM -0400, Chris Pepper wrote:
When you run the viewer for the first time, it picks your device's
default bit depth as the initial setting. Your device merely responded
by saying its bit depth was 1bpp by default :)
Interesting. My Tungsten C was set to 8
41 matches
Mail list logo
