The attached Train.pdb workes fine on my Palm and all the hardware I can
emulate. (Except for the missing last row I just fixed in CVS). Anyone
else see the problem?? I can't test on anything newer than PalmOS 4.
Ardiyanto, what model is your Palm? And the exact version number from
App->Info->Ver
---Reply to mail from Ardiyanto about big table not displayed properly (more bug)
> And to add my previous bug report,
>
> please notice that the last line of the table is not displayed on the "plucker
> viewer", altough it is displayed on the web browser (at desktop)
This one was easy to fi
Plucker currently can't handle a continuous paragraph break--
a paragraph break always forces at least a line break. Alex
- Original Message -
From: Michael Nordstrom <[EMAIL PROTECTED]>
Date: Wednesday, January 21, 2004 1:07 pm
Subject: Re: proposal: exact anchors
> On Wed, Jan 21, 2004
> You still haven't convinced me that the Plucker format
should be
> changed. You *can* handle this using the current format
You mean by breaking up text mid-paragraph, and
occasionally mid-sentence, via a filter that searches for tags?
Note that this is probably quite impossible with somethin
On Wed, Jan 21, 2004, Alexander R. Pruss wrote:
> But the basic thing is this. is supposed to let one go
> straight to the tag. Currently, it doesn't--it goes back
> to the top of the paragraph containing that tag,
You still haven't convinced me that the Plucker format should be
changed. You *
On Wed, Jan 21, 2004, Keith M. Hughes wrote:
> The parser shouldn't create a new paragraph every time it has seen an "a
> name" tag. That tag is not a paragraph creating tag like or .
You make the mistake of assuming that an HTML paragraph is the same
thing as a paragraph in Plucker...
/Mike
_
Test =)
sybbhqmuuwgvcps
--
Test, yep.
<>
> > This just doesn't seem to be the right way of handling HTML named
> > anchors, even if it works for most documents because of the accident
> > that in most HTML documents (I assume) the named anchors are at the
> > beginning of a text.
>
> Lots of HTML is written poorly. We can't do much to hel
> BTW, if you start supporting this for arbitrary places, you should also
> support the id attribute, which allows any element to be used as a
> destination for a
> link. Or does Plucker already do this?
The JPluck parser purports to (I haven't knowingly tried it). Don't think
the python parser
> BTW, if you start supporting this for arbitrary places, you should also
> support the id attribute, which allows any element to be used as a
> destination for a link. Or does Plucker already do this?
Let's also not forget that the 'name' attribute has been dropped
in XHTML 1.1 (and fut
I don't understand why this should be necessary; you can already go to the
"exact" position (if the parser creates a new paragraph when it encounters
an "a name" tag in the text).
The parser shouldn't create a new paragraph every time it has seen an "a
name" tag. That tag is not a paragraph crea
But the basic thing is this. is supposed to let one go
straight to the tag. Currently, it doesn't--it goes
back to the top of the paragraph containing that tag, and it is quite
possible that the place with the tag doesn't even show up on that
screen.
BTW, if you start supporting this for ar
> But the basic thing is this. is supposed to let one go
> straight to the tag. Currently, it doesn't--it goes
> back to the top of the paragraph containing that tag, and it is quite
> possible that the place with the tag doesn't even show up on that
> screen.
It works like this in de
> so - something wrong with the autogen or configure scripts?
Did you run autoreconf in the viewer subdirectory?
d.
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
14 matches
Mail list logo
