et the charset metadata for those
records. It's simple: the metadata is only assigned to the head
record of a sequence, both for continued and linked sequences.
Then imagine a reader is processing a request for a record that is
in the middle of a sequence of linked records. How does the reader
On Mon, Apr 10, 2006 at 09:13:49AM -0400, Alexander R Pruss wrote:
>>Documents generated by older versions of PyPlucker exist.
> Sure, but fixing PyPlucker will not fix these documents. If PyPlucker
> is to be changed, I'd make sure that the continuous page method is the
> default, and that the
David A. Desrosiers wrote:
Is there any reason to worry too much about these old-style links?
There is not much reason for a pyplucker user to generate them nowadays.
Will removing that support break existing Plucker documents that
are distributed on the web today? I know of a lot of pl
Konstantin Khomoutov wrote:
Documents generated by older versions of PyPlucker exist.
Sure, but fixing PyPlucker will not fix these documents. If PyPlucker
is to be changed, I'd make sure that the continuous page method is the
default, and that the other option is marked as deprecated.
Ale
Is there any reason to worry too much about these old-style links?
There is not much reason for a pyplucker user to generate them
nowadays.
Will removing that support break existing Plucker documents
that are distributed on the web today? I know of a lot of places who
have done conversion
On Mon, Apr 10, 2006 at 12:23:42AM -0400, Alexander R. Pruss wrote:
> Is there any reason to worry too much about these old-style links?
> There is not much reason for a pyplucker user to generate them nowadays.
Documents generated by older versions of PyPlucker exist. For
example, I have lots of
Is there any reason to worry too much about these old-style links?
There is not much reason for a pyplucker user to generate them nowadays.
ALex
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133 U.S.A.
e-mail: [EMAIL PROTECTED]
online papers and
Some time ago I started the discussion on similar topic (metadata,
and--especially--charset metadata) of sequences of "continued" text
records in Plucker documents.
Support for them was successfully added to Vade-Mecum, and now I
have questions about how to handle charset metadata of se
On Mon, Mar 01, 2004, Alexander R. Pruss wrote:
> Currently, whenever the metadata format is updated, the old metadata is
> wiped. I wonder if we could keep separate version numbers for bookmark
> data (and annotations, once these appear), so that these wouldn't be lost
> on
On Mon, Mar 01, 2004, Alexander R. Pruss wrote:
> Could someone explain to me how the metadata record and UID numbering works?
It's pretty obvious to me (and explained in the source code), so I'm
not sure what more to explain.
> What would need to happen to insert additional meta
Could someone explain to me how the metadata record and UID numbering works?
What would need to happen to insert additional metadata records for
annotations and an annotation index? Alex
--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133 U.S.A.
e
Currently, whenever the metadata format is updated, the old metadata is
wiped. I wonder if we could keep separate version numbers for bookmark
data (and annotations, once these appear), so that these wouldn't be lost
on a metadata update.
Alex
--
Dr. Alexander R. Pruss || e-mail: [
> Is the metadata
> record used at all by the Viewer?
AFAIK, so far just the GTK viewer shows it, not the
Palm viewer.
Best wishes,
Robert
__
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc
Currently the PalmOS viewer just looks at the Owner ID in the metadata
field.
Bill
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
> I see no way of viewing the contents of the metadata record from within the
> Viewer.
The PalmOS viewer doesn't use that meta data, yet. I think the GTK
viewer uses the meta data, though.
/Mike
___
plucker-dev mailing list
[EMAIL PROT
Hi,
I see no way of viewing the contents of the metadata record from within the
Viewer. I've followed the Plucker format specification and created a
metadata record specifying the author, title and publication date, but I see
no way of checking these fields from within the Viewer. I
Looks great, Dirk. I'll switch over the code in TextParser.py to use it.
Bill
"Dirk" == Dirk Heiser <[EMAIL PROTECTED]> writes:
>>> And at the end one idea: Whats about writing a parser that parse the
>>> http://www.iana.org/assignments/character-sets and create and complete
>>> NamedCharsets array? It seams to be easy and i think i could do this.
Bill>> Great idea!
Dirk
so
FYI: This are the output from python 2.0
>> i get:
>>
>> ---
>> Converted plucker:/home.html
>> Default charset is 1252
>> 1252
>> 0
>> Converted plucker:/~special~/index
>> --
>>
>> and 04E4 (1252) are written in the pl
" form.
> i get:
>
> ---
> Converted plucker:/home.html
> Default charset is 1252
> 1252
> 0
> Converted plucker:/~special~/index
> --
>
> and 04E4 (1252) are written in the plucker DBs metadata record. But
> the http://www.iana.org/assignments/character-
"Dirk" == Dirk Heiser <[EMAIL PROTECTED]> writes:
Dirk> and 04E4 (1252) are written in the plucker DBs metadata record. But
Dirk> the http://www.iana.org/assignments/character-sets say:
Dirk> -
Dirk> Name: windows-1252
Dirk> MIBenum: 2252
Dirk> So
plucker:/home.html
Default charset is 1252
1252
0
Converted plucker:/~special~/index
--
and 04E4 (1252) are written in the plucker DBs metadata record. But
the http://www.iana.org/assignments/character-sets say:
-
Name: windows-1252
MIBenum: 2252
Source: Microsoft (see ../character
> Getting the Default charset (no Charset set in command line or
> plucker.ini) with Python 2.0b1 work fine but using Python 1.52 it does
> not work. Do you have an idea?
No, it doesn't work on UNIX either; the locale.getlocale() call isn't
in 1.5.2. I just punt on that case, and say that the de
"Bill" == Bill Janssen <[EMAIL PROTECTED]> writes:
Bill> locale.setlocale(locale.LC_ALL, "")
Bill> encoding = locale.getlocale()[1]
Bill> If that also fails to produce a charset, the default charset is left
Bill> unassigned. (Using a Solaris 2.6 machine in California, the standard
Bill> ope
> Maybe all these problems will be solved if we use unicode.
Yes, I think that's right. UTF-8 should be able to handle all the
characters in the various character sets you mention.
Bill
I made a mistake about the charsets/codesets. What I meant:
- what if single byte code set is mixed with double byte code set? eg.
iso8859-? with GB2312.80.
- What if two similiar code sets are mixed? eg. GB2312 and BIG5.
All of them create troubles! Unless they are clearly tagged, it is di
> It is a good idea. But what happens when charsets are mixed in one single page
> of the document? This is not the stuff you can always avoid.
Zailong, are you thinking of the multiple code pages in Big5 or
EUC-JP, for instance? These are still single codesets, even though
they have multiple
Hi, Zailong.
> It is a good idea. But what happens when charsets are mixed in one single page
> of the document? This is not the stuff you can always avoid.
There are few (if any) viewers that can handle this scenario. In
addition, web pages are pretty much required to be in a single
charset.
<[EMAIL PROTECTED]> wrote:
> Folks,
>
> I've modified the parser to look for character set information, and
> add it to the Plucker DB, in the manner that we dicussed a few weeks
> ago. If a default character set is detected, it creates a record of a
> new kind (M
Folks,
I've modified the parser to look for character set information, and
add it to the Plucker DB, in the manner that we dicussed a few weeks
ago. If a default character set is detected, it creates a record of a
new kind (METADATA), and writes the IANA MIBenum for that charset in
th
30 matches
Mail list logo
