Michael:

>> A) refer to (relative or absolute) location (include path in xoj)
>> B) include in xoj (as encoded content of an element)
>> C) copy file to foo.xoj.<special ending>  and refer to that
>> C') derive a rendered version and apply C to that

* About B:

The standard version of xournal never does B, because encoding of 
typically compressed binary data into a text format that later gets 
re-compressed by gzip seems inefficient. But there's nothing inherently 
wrong with it.

I believe the image patch for xournal does B for images added as objects 
on the page, which seems reasonable to avoid proliferation of companion 
files.

This is one of the reasons that Andreas may have in mind for later 
switching to zip instead of gzip: gzip compresses a single stream, while 
zip is an archive format for a collection of files. While I'm not 
thrilled by the prospect of such a break in compatibility, it's a 
sensible long-term plan.

* About C':

It's a historical abomination. Xournal does this for PS and PDF 
backgrounds loaded by "Load background". In a very early version, bitmap 
backgrounds were there but PDF backgrounds weren't yet, so the way to 
get a PS or PDF background was to render it to a bitmap using ghostscript.

This stayed on later on, because of the restriction on PDF backgrounds 
that one can only reference a single PDF file; so in theory if you 
really wanted to have a .xoj file annotate two different pdf files and 
were willing to have one of them converted to bitmap, you could still do 
it that way. It should probably have been removed though, given the lack 
of use and low efficiency of converting to bitmap.

* About A and C: this is what the "attach" toggle was meant to do. It 
works for "Annotate PDF", and for me it also works properly for PNG 
bitmap backgrounds with "Load background".


>> xournal does this with "not attached" (checkbox not checked):
>>
>> background pdf: C', e.g.
>> <background type="pixmap" domain="attach" filename="bg_1.png" />
>> with a rendering of the pdf in<xojname>.bg_1.png
>>
>> I'm really wondering why it's doing that (rather then referring to the pdf).

Because "load background" is orthogonal to "annotate PDF", and a xoj 
file cannot refer to more than one pdf file. But as mentioned above it's 
mostly a historical abomination.

>> With the "attach" checkbox checked, xournal does:
>>
>> background png: A, e.g.
>> <background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" />

Test again. With the "attach" checkbox checked on a background png, I get

<background type="pixmap" domain="attach" filename="bg_1.png" />

> xournalpp does it right for png-backgrounds, i.e. it does C or A
> depending on "attach". So it is incompatible ;)

No, it does the same as xournal. Anyway, this is not the kind of 
meaningful incompatibility that you'd worry about. Changing a 
questionable behavior is fine as long as it doesn't seriously break 
interoperability.

> I can't get pdf-backgrounds to work - I always get "You don't have any
> PDF pages to select from" (Journal->Paper background->PDF) even when the
> "insert type" is set to PDF. Does this work when annotating only?

I'm not familiar with xournalpp enough to answer, but my guess is that 
it's a similar issue to xournal, i.e. you should be annotating, not 
loading a background.

>> Given that situation, I'm not sure that compatibility would be the best
>> goal here... But in fact (and no matter what to do with the non-working
>> background-attach option), to be as compatible and consistent as
>> possible, xournalpp should never do B (xournal never did B), and
>> inserted images should do C (by default)! As a positive side effect, the
>> xml machinery would not have to deal with large binary-to-text-encoded
>> blobs. Also, implementing A as an option for inserted images  would be
>> simpler then. I think the B-doing patch for xournal really lead us on a
>> wrong path in this respect.

I think you're just over-analyzing things. As you said, compatibility 
doesn't mean "do exactly the same in all instances", it just means 
having a reasonably familiar behavior, and having file formats that can 
be read by each other (with degradation for features of xournalpp that 
xournal doesn't recognize right away, such as image objects on the page 
-- which the standard xournal ignores silently and just skips).

> Compatibility is important, of course, but:
>
> - don't be compatible to bugs (you corrected some of xournal's)
> - don't be compatible to patched versions (when they set a wrong precedent)

Ok then we agree.

By the way, somewhere there was also a discussion of whether xournal 
ignores or rejects tags that it doesn't recognize when loading. The 
answer is:

- attributes of XML tags are very rigid: they should indeed come in the 
correct order (to some extent), and the list of attributes has to match 
exactly one of the allowed cases. (so for example <background> takes 
"domain" and "filename" attributes only if "type" is "pixmap" or "pdf", 
and in that case they must be present in that order).

- on the other hand, inserting new XML tags into the structure is 
backwards compatible. The tags themselves will just be silently ignored 
by xournal upon loading the file, but the sections of text they enclose 
are still processed as if the unknown tag were not surrounding them. And 
contents that are within tags that don't expect content are also 
silently ignored.

So: there are several reasonable backward compatible ways to extend the 
file format. If you need to extend e.g. the "background" tag, you can do 
either

<background type="pixmap" domain="attach" filename="bg_1.png">
<bgdata rescale="1.5" margins="200" />
</background>

(to extend the "background" tag if needed by adding extra flags within a 
nested tag called "bgdata" in this example); or

<backgroundpp .... />
<background ... />

(to first specify a background in your favorite manner with all the 
extended tags, then provide a fallback compatibility background tag for 
the old xournal, which xournalpp will ignore if it comes after a 
new-format background tag); or in nested fashion

<backgroundpp ...>
<background ... />
</backgroundpp>

(and then you'd tell your loader to ignore a "background" tag if the 
surrounding tag is "backgroundpp").
To have new types of objects (e.g. as in the image patch), there's just 
no problem, namely inside a layer you can have

<image ...> inline data </image>
or
<image ... />

In all these cases you'll be safely readable by old-xournal. Sorry that 
tags are not extensible by default and that the workarounds aren't 
completely clean; but as you can see it's not a huge constraint, 
especially since the format is not meant to be written/read by humans.

Best,
Denis


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel

Reply via email to