I wish that it did work, but it does not as I mentioned below. Since
posting this, I was successful at taking a <keyUID>.some.pdf.xml file,
transferring it between systems and changing the path as I suggested
below, but that is a lot more work than I would like. Is there some log
or something that I can check to determine why using a document archive
is not storing/retrieving new annotations?
I realize that I'm using two different versions of the app between
systems, but both are capable of reading and writing an archive.
-=> Gregg <=-
On 05/30/2012 06:08 PM, Albert Astals Cid wrote:
> El Dimecres, 30 de maig de 2012, a les 15:59:14, Gregg Leichtman va escriure:
>> Is there an easy way to continue annotating a pdf file between Linux and
>> Windows without losing previous annotations?
> Always use "Export as Document Archive". That should work.
>
> Albert
>
>> I am using Okular 0.14.0 on Windows XP SP3 via KDE for Windows 4.8.0 and
>> Okular 0.13.2 on OpenSuse 12.1.
>>
>> I see that I can create a document archive that can be transferred from one
>> system to another, but when I try to annotate the loaded ocular archive
>> (zip) file, it succeeds but does not save it (not really a surprise, since
>> it is a zip file). I also see the XML files in the archive---metadata.xml
>> and content.xml---where metadata.xml appears to be the very similar to the
>> annotation files stored under Windows at:
>>
>> A) C:\Documents and Settings\<yourLoggedInUserProfile>\Application
>> Data\.kde\share\apps\okular\docdata\<someKeyUID>.<yourfile>.pdf.xml
>>
>> and under Linux at
>>
>> B)
>> <yourHomeDirectory>/.kde4/share/apps/ocular/docdata/<someKeyUID>.<yourFile>
>> .pdf.xml
>>
>> with very small differences described below and the content.xml file just
>> ties the pdf and metadata.xml files together in the archive.
>>
>> Based on this it doesn't look like a raw document archive is the ticket. I
>> imagine that I could continue to have the pdf file on both systems and then
>> transfer the annotation files between A) and B) above if I understood the
>> significance of the keyUID filename prefix (my guess is that it is just a
>> UID (possibly a hash of the file path), so that the same pdf file in
>> different locations of the same file system don't collide when they are
>> both independently annotated), but is there an easier way?
>>
>> The difference in the metadata.xml file in the archive appears to be almost
>> identical to the files A) and B) except that the documentInfo URL attribute
>> has been stripped along with a small number of other seemingly low
>> importance variations. For example:
>>
>> diff metadata.xml 13227877.some.pdf.xml
>> 3c3
>> < <documentInfo>
>> ---
>>
>>> <documentInfo url="/a/url/to/a/pdf/some.pdf">
>> 1809a1810,1829
>>
>>> <generalInfo>
>>> <history>
>>> <oldPage viewport="146;C2:0.4995:0.975965:1"/>
>>> <oldPage viewport="147;C2:0.4995:0.013834:1"/>
>>> <oldPage viewport="146;C2:0.4995:0.975965:1"/>
>>> <oldPage viewport="147;C2:0.4995:0.962451:1"/>
>>> <oldPage viewport="148;C2:0.4995:0.965721:1"/>
>>> <oldPage viewport="149;C2:0.4995:0.288142:1"/>
>>> <oldPage viewport="130;C2:0.49949:0.849155:1"/>
>>> <oldPage viewport="131;C2:0.49949:0.420097:1"/>
>>> <oldPage viewport="142;C2:0.49949:0.98029:1"/>
>>> <oldPage viewport="143;C2:0.49949:0.98749:1"/>
>>> <current viewport="144;C2:0.49949:0.412309:1"/>
>>> </history>
>>> <views>
>>> <view name="PageView">
>>> <zoom mode="1" value="1.89755"/>
>>> </view>
>>> </views>
>>> </generalInfo>
>> Would it be as "simple" as creating an application import menu item that
>> unpacks the archive, places the pdf at the location of the archive, adds
>> the URL attribute to the documentInfo element and deals with the other
>> small variations (in this case what appears to be storage of the navigation
>> history and the current page view type and zoom factor) and then moves the
>> metadata.xml file into the path for A) or B) along with a file rename?
>>
>> -=> Gregg <=-
>>
>> This message is intended for the exclusive use of the individual or entity
>> that is the named addressee and may contain information that is privileged
>> or confidential. If you are not the named addressee or an employee or agent
>> responsible for delivering this message to the named addressee, you are not
>> authorized to read, print, retain, copy or disseminate this message or any
>> part of it. If you have received this message in error, please notify us
>> immediately by e-mail, discard any paper copies and delete all electronic
>> files of the message
>>
>>
>> _______________________________________________
>> Okular-devel mailing list
>> Okular-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/okular-devel
> _______________________________________________
> Okular-devel mailing list
> Okular-devel@kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel
>
_______________________________________________
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel
