Andreas Butti venit, vidit, dixit 18.04.2011 17:12:
> 
>>>> Regarding Images:
>>>> Having the option to not attach them (just like backgrounds) would be
>>>> really nice, with an element like:
>>>>
>>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28"
>>>> filename="bg_1.png"/>
>>> why?
>>>
>>> The Image format I use is 100% compatible with the pach which is
>>> available for Xournal on sf.net
>> It's good to have it compatible (though that patch never made it into a
>> released version), but still the extension with 'filename=""' would not
>> break it.
> 
> Are you sure? Try it out;-)
> 
> Xournal has for reading always a loop which checks every attribute, if 
> you have an attribute more it don't read the whole file.

That's not good. It should ignore that element only. Does it ignore
unkown elements?

> 
> That's the reason why I leave everything exactly the same. (Even if you 
> change the order of attributes it don't read the files any more).

Uh. XML parser anyone? ;)

> For me personal I said I leave it in the first release 100% compatible 
> with Xournal (and optional with the image patch). And if all is working, 
> the next release will use a new fileformat which is not compatible, but 
> contains resources and new features.
> 
> (based on ZIP instead of GZip)

What is the advantage of ZIP over GZip?

On compatibility: I noticed that for a file "foo.xoj", xournalpp
suggests "foo.xoj.pdf" for the exported pdf while xournal suggests
"foo.pdf". Is that change intentional?

>> Not attaching images is important because of file size, especially, but
>> not only when you include the same image several times. I would say it's
>> important for the same reasons out which backgrounds can be attached or
>> detached.
> This is an argument for using attaching images...
>> Also, imagine using a "library" of images that you include again and
>> again, or a workflow where you regenerate the image and want your xoj to
>> use the regenerated image automatically.
> This is no argument for attaching images, this is in my opinion against, 
> because the data is may inconsistent.

I want it up to date with regenerated images in this case. Because that
would be the "consistent" state in some use cases.

I'm not arguing for a different default; I'm just claiming that there
are use cases where you want to stay the image or background in the
state from the time of inclusion and other use cases where you want an
image or background to follow the state of a referenced file (like
xournal's defaulft for annotated pdf's).

> 
> There is a Python API for Xournal++, which is not finished yet, and at 
> the moment only used for testing, but later you should write a Python 
> Plugin for this, so there is for sure no inconsistency.
> 
>>> For future releases I'll create a new format (e.g. based on ZIP) which
>>> can handle resources better.
>>>
>>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image
>>>> background, but the filename is "wrong". But then it does find it on
>>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image
>>>> backgrounds is great and just what I would love for detached image
>>>> objects also :)
>>> I'll check this, I don't understand what you mean now, but I didn't
>>> really test background image yet;-)
>> Journal ->  paper background ->  Image: select "bend.png"
>> Save xoj.
>>
>> The xoj is:
>>
>> <?xml version="1.0" standalone="no"?>
>> <xournal creator="Xournal++ 0.1" fileversion="2">
>> <title>Xournal document - see http://xournal.sourceforge.net/</title>
>> <preview>...</preview>
>> <page width="22.00" height="31.00">
>> <background type="pixmap" domain="attach" filename="bg_1.png"/>
>> <layer/>
>> </page>
>> </xournal>
>>
>> Different filename. But when I close and reopen xournalpp finds it or
>> rather: I see now that there is a copy
>>
>> 2011-04-18-Note-15-07.xoj.bg_1.png
>>
>> in my workdir. Is that (copying background images) how it works with
>> xournal trunk?
> On the open dialog is a checkbox, "Attach to Xournal". Even on my 
> application (but in Xournal++ it's may not working correct;-))

Sure, but "attach" does something different from what I expected. My
fault... There are 3 ways in which an image (inserted or background) or
pdf (annotated or background) can be treated:

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

I wasn't aware of C until yesterday and thought "attach" does B. xournal
does this with "not attached" (checkbox not checked):

annotated pdf: A, e.g.
<background type="pdf" domain="absolute" filename="/tmp/a/bend.pdf"
pageno="1" />

background png: A, e.g.
<background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" />

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).

With the "attach" checkbox checked, xournal does:

annotated pdf: C, e.g.
<background type="pdf" domain="attach" filename="bg.pdf" pageno="1" />
with a proper copy of the pdf

background png: A, e.g.
<background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" />

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

That is, the "attach" checkbox does not even seem to work for
backgrounds, and xournal always does C' (attach a rendered png) for
pdf-backgrounds and A (refer to original png) for png-backgrounds.

With the image patch for xournal, early version would do A and later
versions would do B.

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.

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

Reply via email to