Hi Denis: Denis Auroux venit, vidit, dixit 19.04.2011 19:42: > 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.
Yes, and I think I mentioned that. > > 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. Reminds me of odf, btw. I'm wondering whether their content.xml allows detached objects. > * 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" /> Sure enough, it does today with the same png. Sorry for the false report. > >> 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. With xournal, I can "load background" a pdf (which gets attached as png). With xournalpp, I can set the "insert page type" to pdf and I can set the "paper background" to pdf. No matter what I do (set paper bg, insert new page etc.) I get that error message. Even today! >>> 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 Being an analyst at heart I take that as a compliment... Seriously, since xournalpp is taking a fresh start it's good to analyze some things before one starts coding and creates compatibility issues later on. I'm bitten by my experience with other projects where "compatibility" is a big hurdle for any ui improvements. (Also, I really would like detached image objects for my lecture notes, but that is a hidden agenda that I'm not telling anyone.) > 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. I think so :) [xml discussion snipped] Cheers, Michael ------------------------------------------------------------------------------ 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
