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