subpage search and line spacing
Subpages search and line spacing features are implemented in the viewer (unstable branch). Sample binary is placed at http://www.chem.nagoya-u.ac.jp/~matto/90/30Palm/plucker/20021121en.prc You will see the importance of line spacing for easy reading. matto ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Non-HTML (was Re: Back/foward/home function code)
Chris Combs <[EMAIL PROTECTED]> wrote: > s/<\![^>]*>//g; Won't that catch valid things like CDATA? -- MJR ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
> What I am saying is that by hardcoding absolute pixels for indentation - by > setting the left and right margin - the resulting document will not be > compatible across platforms and different resolutions. ... > In other words, creating indentations for bulleted or numbered lists using > hardcoded margins will only work if you know the device resolution and font > size at the time of document creation. So the responsibility of creating a > visually good document lies with the parser and not the viewer. We discussed this about four weeks ago, didn't we? I agree it's a problem (I don't agree it's a distiller problem, though), and I think that future versions of the document format should do this differently. I don't know that I know what "proper alignment" of the text should be, though. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
Bill Janssen wrote: > The middot character is just too small on PalmOS to use, and besides, > there's a bullet in the standard set of glyphs on the Palm. Sorry, I meant #149, which is what I'm using for the bullet, not the middle dot. > "Properly"? You mean just turning the viewers into HTML viewers, and > just putting raw HTML in the document? Remember that the Plucker > document format is not HTML, but rather a more presentational and > simpler format. What I am saying is that by hardcoding absolute pixels for indentation - by setting the left and right margin - the resulting document will not be compatible across platforms and different resolutions. In fact, I'm now looking at a document in the hires Viewer in a POSE N710C session (320x320) and the indentation for bulleted lists is indeed wrong. The text is not aligned properly. This occurs both with a document generated by the Python parser (the one that uses the o) and a JPluck-generated document, BTW. If I look at the document in a 160x160 session then the list displays correctly. In other words, creating indentations for bulleted or numbered lists using hardcoded margins will only work if you know the device resolution and font size at the time of document creation. So the responsibility of creating a visually good document lies with the parser and not the viewer. This is fine with me, but this also implies that if you distribute ready-to-install PDBs (e-books) you should make multiple versions available. That is, if you use bulleted or numbered lists in your documents. So maybe there is a case for creating a function code for hanging indents, so the bullet and the text can display with the correct indentation across different resolutions and font sizes. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
On 20 Nov 2002 at 14:56, Bill Janssen wrote: > > I also think it is incorrect rendering. > > Is there an alternative way to have a 1st column of preformatted font, and the >rest of the line > > in normal font in the current parser (or is CSS required?) > > Whoa! "column" is a loaded phrase. > > I'd think > > one this is the rest of this line > > should work, but haven't tried it. > > Bill That is exactly what I was looking for. Thanks! Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
Just to complete this answer, the list of Unicode characters translated properly for the Latin-1 PalmOS viewer lives in viewer/os.c. Currently, the list includes en-dash and em-dash left or right single or double quotation mark bullet horizontal ellipsis trade-mark sign Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
> I also think it is incorrect rendering. > Is there an alternative way to have a 1st column of preformatted font, and the rest >of the line > in normal font in the current parser (or is CSS required?) Whoa! "column" is a loaded phrase. I'd think one this is the rest of this line should work, but haven't tried it. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
> > > > a > > b > > c > > > > is displayed as > > > > a b c > > > Seems wrong to me. Please file a bug report. I also think it is incorrect rendering. Is there an alternative way to have a 1st column of preformatted font, and the rest of the line in normal font in the current parser (or is CSS required?) ie, is it possible, without using pre tags, to have a line in the viewer that renders as: this-word-in-preformatted-font this-word-in-normal-font Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
Laurens M. Fridael wrote: > Bill Janssen wrote: >> The current CVS version of the viewer should in fact use middle-dot; >> I put that code in myself. > > You're talking about the parser right? Not the viewer. > Forget about that question. Your other reply explains it. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
Bill Janssen wrote: > The current CVS version of the viewer should in fact use middle-dot; I > put that code in myself. You're talking about the parser right? Not the viewer. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
Seems wrong to me. Please file a bug report. Bill > > a > b > c > > is displayed as > > a b c > ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
Laurens writes: > Why does the Python parser not use the middle dot (#183 in the ISO-8859-1 > set) for the bullet? It generates this small o that just looks out-of-place. > The Plucker document specification states that text records are a stream of > ISO-8859-1 characters, so why not use the middle dot? Whoops, I mis-answered this. Sorry. The current distiller code inserts the Unicode "bullet" character for this purpose, and uses "o" as the text to insert if your viewer doesn't understand Unicode. All the viewers I've had a finger in will (the PalmOS viewer post 1.2, and the GTK+ viewer) will properly display the bullet character when it's encountered. The middot character is just too small on PalmOS to use, and besides, there's a bullet in the standard set of glyphs on the Palm. > I think there is a case for supporting lists properly, with the proper > indentation so they look right, rather than relying on hard-coded margin > formatting to get the intended effect. Unless there is something I'm > overlooking. "Properly"? You mean just turning the viewers into HTML viewers, and just putting raw HTML in the document? Remember that the Plucker document format is not HTML, but rather a more presentational and simpler format. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulleted lists and indentation
The current CVS version of the viewer should in fact use middle-dot; I put that code in myself. Bill > Why does the Python parser not use the middle dot (#183 in the ISO-8859-1 > set) for the bullet? It generates this small o that just looks out-of-place. > The Plucker document specification states that text records are a stream of > ISO-8859-1 characters, so why not use the middle dot? ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
> As Plucker continues to rise, I would offer that Plucker chooses the > best practices, in the form of documented W3C and ISO standards, > instead of picking up the bad practices of the withering commercial > off-line browsers. Indeed. I'm spending my time working on CSS support, not worrying about some odd feature some other soon-to-bankrupt commercial venture has mistakenly introduced. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
> If you started to use a differet system for communication then I > can point out one major disadvantage: > > - some core developers will be missing I'm with Michael on this one. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Please add a feature request to the bug tracker. > Wesley Mason wrote: > > Ok... > > > > Can we, for argument sake, in the parser have it translate the > > pods://avantgo/back link to a link to the prior page? > > > > I think this solves alot of the problems. > > I totally agree. This is the best solution for now. > > > Regards > -Laurens > ___ > plucker-dev mailing list > [EMAIL PROTECTED] > http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
> Can we, for argument sake, in the parser have it translate the > pods://avantgo/back link to a link to the prior page? > > I think this solves alot of the problems. It would if the distiller kept that info, but it doesn't (and it would be very difficult to keep it correctly, since the order in which pages are gathered doesn't really depend on the links which point to them). Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Line spacing
On Wed, Nov 20, 2002, masakazu wrote: > May I add a feature to change line spacing in prefs panel? The code in the unstable branch is open for more or less any kind of new features. However, all features in the unstable branch will not necessarily make it into the stable version ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
On Wed, Nov 20, 2002, masakazu wrote: > Is this a problem of the viewer or the parser? Run it in a debugger and you will find the answer to that question ;-) In other words, if there are "newline" function codes in the Plucker document then it is a viewer problem, but if no "newline" codes have been included then it's a parser problem. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Exclusion lists (Was Re: PlkrData Alpha Up)
> >Probably a exclusion INI entry would have easier maintainabilty vis-a-vis
> >a blob of binary
> >data.
> >Yes, there would be a few lines added to the Python parser in the
> >ExclusionList.py file to add
> >the entries to the exclusions. The Desktop would read/write to the INI
> >instead of a
> >exclusionlist for that channel.
> >
> >As a general strategy, one could define:
> >
> >parse_exclusion_entry(self,line)
> > m = re.match (r"([-+]?\d+):([-+]):(.*)", line)
> > if not m:
> > error ("ExclusionList: Cannot parse line: %s\n" % orig_line)
> > else:
> > prio = int (m.group (1))
> > action = m.group (2) == '+'
> > regexp = m.group (3)
> > new_item = (action, regexp)
> > if self._items.has_key (prio):
> > self._items[prio].append (new_item)
> > else:
> > self._items[prio] = [new_item]
> >
> >by taking the above out of the load_file, calling it
> >parse_exclusion_entry(), and then write a
> >new entry that loops the keynames from the config. So it would be
> >
> >def load_file(self,filename)
> > ...(existing loop of number of lines in file)
> > line = (the existing strip of the /n)
> > parse_exclusion_entry(line)
> >
> >def load_exclusion_entries_from_ini(self)
> >
> > line = read ini to get line
> > parse_exclusion_entry(line)
> >
> >Best wishes,
> >Robert
>
> Okay, is this a proposal or merely a discussion? I ask because if the
> former, what I'd like to do is have PlkrData move the exclusion from
> whichever source (INI or file) it is on the source, to the INI on the
> destination. But that will require users upgrade to the newest Plucker
> Desktop (i.e. current + 1), which would include not just INI exclusion
> editing support in the dialogs but also a new parser prior to the normal
> (slower) release schedule.
All sounds reasonable.
Best wishes,
Robert
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Exclusion lists (Was Re: PlkrData Alpha Up)
> Okay, is this a proposal or merely a discussion? I ask because if the > former, what I'd like to do is have PlkrData move the exclusion from > whichever source (INI or file) it is on the source, to the INI on the > destination. ..as long as you don't break existing functionality, i.e. retain the use of external exclusion lists, and don't make it a requirement to use these tools and methods in each of the other tools. Each "third party" tool should be an add-on, not a replacement, of existing functionality, i.e. they should stand alone, and not replace or supplant existing code in the other tools. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Exclusion lists (Was Re: PlkrData Alpha Up)
At 02:37 PM 11/20/2002 +, Robert O'Connor wrote:
> Therefore, it was put forward, to include exclusions
> >as numbered keys,
> >using the existing method of an exclusion list entry. For example:
> >exclusion_item1=0:-:.*\.mp3$
> >exclusion_item2=0:-:http://.*www.x10.com/.*
> >The parser would then loop through a section, looking to see if there was
> >the next incremented
> >number of key, and if so, add that exclusion to the active exclusions.
>
> This raises an issue of interfaces. Certainly we could move exclusions to
> Plucker.INI, but for much of my parser testing (like when I was adding
> --stayondomain) I ran Plucker from the command line without a
corresponding
> INI channel. Doing that, I can load exclusion lists from the
> command-line. So I certainly wouldn't want to completely deprecate
> exclusion files.
Absolutely. Would always continue the existing support for dedicated
exclusion lists, for both
compatibility and because it is helpful.
> On the other hand, I also agree that all channel-specific configuration
> data should go in a single place, and the INI file is a good contender for
> that.
>
> But either way, that's not in the Parser nor would Desktop see them or
save
> exclusions there itself, so there's not much point in doing it in PlkrData
> right now. The exclusion list has GOT to wind up in a file on the other
> side. So packaging it as an encoded blob is probably faster than
> enumerating through a series of keys.
Probably a exclusion INI entry would have easier maintainabilty vis-a-vis
a blob of binary
data.
Yes, there would be a few lines added to the Python parser in the
ExclusionList.py file to add
the entries to the exclusions. The Desktop would read/write to the INI
instead of a
exclusionlist for that channel.
As a general strategy, one could define:
parse_exclusion_entry(self,line)
m = re.match (r"([-+]?\d+):([-+]):(.*)", line)
if not m:
error ("ExclusionList: Cannot parse line: %s\n" % orig_line)
else:
prio = int (m.group (1))
action = m.group (2) == '+'
regexp = m.group (3)
new_item = (action, regexp)
if self._items.has_key (prio):
self._items[prio].append (new_item)
else:
self._items[prio] = [new_item]
by taking the above out of the load_file, calling it
parse_exclusion_entry(), and then write a
new entry that loops the keynames from the config. So it would be
def load_file(self,filename)
...(existing loop of number of lines in file)
line = (the existing strip of the /n)
parse_exclusion_entry(line)
def load_exclusion_entries_from_ini(self)
line = read ini to get line
parse_exclusion_entry(line)
Best wishes,
Robert
Okay, is this a proposal or merely a discussion? I ask because if the
former, what I'd like to do is have PlkrData move the exclusion from
whichever source (INI or file) it is on the source, to the INI on the
destination. But that will require users upgrade to the newest Plucker
Desktop (i.e. current + 1), which would include not just INI exclusion
editing support in the dialogs but also a new parser prior to the normal
(slower) release schedule.
Make sense?
-Tony McNamara-
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Exclusion lists (Was Re: PlkrData Alpha Up)
> Therefore, it was put forward, to include exclusions
> >as numbered keys,
> >using the existing method of an exclusion list entry. For example:
> >exclusion_item1=0:-:.*\.mp3$
> >exclusion_item2=0:-:http://.*www.x10.com/.*
> >The parser would then loop through a section, looking to see if there was
> >the next incremented
> >number of key, and if so, add that exclusion to the active exclusions.
>
> This raises an issue of interfaces. Certainly we could move exclusions to
> Plucker.INI, but for much of my parser testing (like when I was adding
> --stayondomain) I ran Plucker from the command line without a corresponding
> INI channel. Doing that, I can load exclusion lists from the
> command-line. So I certainly wouldn't want to completely deprecate
> exclusion files.
Absolutely. Would always continue the existing support for dedicated exclusion lists,
for both
compatibility and because it is helpful.
> On the other hand, I also agree that all channel-specific configuration
> data should go in a single place, and the INI file is a good contender for
> that.
>
> But either way, that's not in the Parser nor would Desktop see them or save
> exclusions there itself, so there's not much point in doing it in PlkrData
> right now. The exclusion list has GOT to wind up in a file on the other
> side. So packaging it as an encoded blob is probably faster than
> enumerating through a series of keys.
Probably a exclusion INI entry would have easier maintainabilty vis-a-vis a blob of
binary
data.
Yes, there would be a few lines added to the Python parser in the ExclusionList.py
file to add
the entries to the exclusions. The Desktop would read/write to the INI instead of a
exclusionlist for that channel.
As a general strategy, one could define:
parse_exclusion_entry(self,line)
m = re.match (r"([-+]?\d+):([-+]):(.*)", line)
if not m:
error ("ExclusionList: Cannot parse line: %s\n" % orig_line)
else:
prio = int (m.group (1))
action = m.group (2) == '+'
regexp = m.group (3)
new_item = (action, regexp)
if self._items.has_key (prio):
self._items[prio].append (new_item)
else:
self._items[prio] = [new_item]
by taking the above out of the load_file, calling it parse_exclusion_entry(), and then
write a
new entry that loops the keynames from the config. So it would be
def load_file(self,filename)
...(existing loop of number of lines in file)
line = (the existing strip of the /n)
parse_exclusion_entry(line)
def load_exclusion_entries_from_ini(self)
line = read ini to get line
parse_exclusion_entry(line)
Best wishes,
Robert
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
Dave Maddock wrote: > I think this is a great idea. I'd be willing to help out. I've been > meaning to write a guide for Pluckerbooks (with an ebooks slant of > course) for some time, but it would be nice to have an 'official' > plucker guide. Great! I'll start on it in December. Hopefully I'll have something to show early next year. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
newline in env
Recently I noticed that the implicit newline (i.e. newline without ) in environment is eliminated. i.e. a b c is displayed as a b c , not a b c in the viewer. Is it correct? Is this a problem of the viewer or the parser? I'm using the newest unstable viewer. matto ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Bulleted lists and indentation
Hi, Why does the Python parser not use the middle dot (#183 in the ISO-8859-1 set) for the bullet? It generates this small o that just looks out-of-place. The Plucker document specification states that text records are a stream of ISO-8859-1 characters, so why not use the middle dot? I've implemented parsing and generation of bulleted and ordered lists ( and ) in JPluck, which does use the middle dot. It looks great BTW. Nested lists are also supported well with proper indentation for different list levels. However, I can only get the indentation right by "cheating"with margin functions. Now, it seems to me that this method is not compatible across platforms and different device resolutions, since the margin function uses absolute pixels rather than relative widths. Or do the different viewers takes this into account and scale the margins properly? I think there is a case for supporting lists properly, with the proper indentation so they look right, rather than relying on hard-coded margin formatting to get the intended effect. Unless there is something I'm overlooking. Regards -Laurens ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Line spacing
May I add a feature to change line spacing in prefs panel? Default gap between lines is sometimes too small for reading when using small hires fonts. Actually we can change alphabetic font metric using some utility like font hack 123, but there is no utilities for multibyte characters. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
