[Scribus] new document format (was: Ideas on collaboration)

[Oleksandr Moskalenko]

* Craig Ringer <craig at postnewspapers.com.au> [2005-06-23 02:16:03 +0800]:

> Oleksandr Moskalenko wrote:
> 
> >    <canvas id="canvas0" width="8.5" height="11.0" sizeunit="in">
> > 
> >
> I feel nervous about permitting various units in the doc format its 
> self. I guess it's very useful for preserving exact and readable 
> quantities given the unpleasant limitations of binary floating point 
> numbers, and we can always store all units in some sort of 
> 'ScMeasurement' class with overloads for add, subtract, divide, etc and 
> always casts to a value in pt, though. Might be an issue for external 
> manipulators of the data, but probably not that bad... so I guess I'm 
> behind the idea. I don't particularly like the complexity and potential 
> performance/memory concerns of having to use special unit classes like I 
> expect we'll have to in order to preserve those exact quantities across 
> load/save, though.

I am not sold on the idea that everything should be stored in the same unit as
users really might not like it, though the alternative choice might introduce
errors during the conversion. I'm not sure what the right way to do it, yet.
I was told by Craig B. that internal calc is done in pts already. We have to
have a thorough discussion about it when I get back from a trip in a couple of
days.

> Also ... if we're preserving exact units, perhaps we should be doing so 
> on a per-measurement level by keeping unit suffixes, eg "100mm". I don't 
> know if it matters, but to me that'd feel ... "neater". So long as the 
> suffixes were restricted to a particular set (I know we couldn't 
> validate this in the DTD) and the formatting was strict, that is. If we 
> went that way (and I'm not saying I particularly think we should, it's 
> just an idea) defining a default unit if there was no suffix (probably 
> pt) would probably be best too.

Default unit is fine. I have it as "mm" right now, but "pt" is just as well.

> >        <canvasobjects>
> >                <imgframe id="fimg0" width="200" height="200" sizeunit="mm"
> >                    origin="ltop" xorigin="400" yorigin="500" 
> >                    origunit="mm">
> > 
> >
> I assume "origin" relates to the page the item belongs to, eg "top left 
> of the main page the item appears on"?

Origin and coordinates are all about the canvas these days. The only
connection to the page is by reference, so if a page is moved, objects can be
updated, too.

> >                    <img id="img0" src="img0" type="png" width="100"
> >                        height="100" sizeunit="px" resolution="150"/>
> > 
> >
> Minor point - resolution will need to be 'xres' and 'yres', not just 
> 'resolution', unless the plan is to store 'resolution="150x120"'. Also, 
> should we be storing resolution in the first place (do we need it) ?

Duly noted.

> We also need to allow for timestamp (modification time), size in bytes 
> (again, for change detection), and maybe even sum / md5sum. I think 
> allowing for the optional storage of a preview quality image, probably 
> required to be a particular format (eg PNG),  in the document its self 
> may also be well worth doing. If we end up with a "zip-style" doc it 
> could go in the bundle, of course, but otherwise allowing for it inline 
> is IMO important so that (a) if we can't find the image, we can still 
> show a preview overlaid with an "image missing" message, and (b) we can 
> potentially avoid loading images on startup by checking their timestamp 
> and size then using our existing preview. The latter will be utterly 
> crucial for network use, especially over WANs or the Internet.

Will do.

> >                </imgframe>
> >                <imgframe id="fimg1" width="100" height="150" sizeunit="mm"
> >                origin="ltop" xorigin="200" yorigin="250" origunit="mm">
> >                <img id="img1" src="img0" type="png" width="100" 
> >                height="100"
> > 
> >
> Maybe "type" should be MIME type, eg "image/png" ? Think "application/pdf".

Those are "internal types" defined through NOTATION with references to
the proper public identifiers. I've looked at how other people implemented
this and went along.

> >                <textframe id="ftxt0" width="300" height="200" 
> >                sizeunit="px"
> >                    origin="ltop" xorigin="100" yorigin="700" 
> >                    origunit="mm">
> >                    <paragraph id="par0" parstyle="parstyle0">
> >                        <text parentpar="par0" txtstyle="txtstyle0"> Hello 
> >                        World!
> >                            This is a test document for the new Scribus 
> >                            file
> >                            format.</text>
> >                    </paragraph>
> >                </textframe>
> > 
> >
> Looks good to me. I presume inline markup would be permitted in paragraphs?

What markup do you have in mind?

> >        </canvasobjects>
> >        <scratchspace id="scratch0" canvasid="canvas0" visible="yes" 
> >        printable="no">
> >            <imgframeobj idref="fimg2"/>
> >        </scratchspace>
> >        <page id="page0" width="8.5" height="11.0" sizeunit="in" 
> >        origin="ltop"
> >            xorigin="40" yorigin="40" origunit="px" orientation="portrait">
> > 
> >
> It might be an idea to store the "paper format name" eg "A4" too, 
> especially when user-defined page sizes are involved.

I didn't do that because I thought Tsoots already did that with the
preferences code. We'll have to merge the pdfoptions and preferences dtds into
the main one soon, too, at least to avoid confusion.

> >            <layer id="layer0" name="Background" level="0" visible="yes"
> >                printable="yes">
> >                <imgframeobj idref="fimg0"/>
> >                <textframeobj idref="ftxt0"/>
> >           </layer>
> >        </page>
> >    </canvas>
> >
> > 
> >
> It's looking better and better every time I see this stuff ... very 
> exciting. Thanks again for doing all this!
> 
> --
> Craig Ringer

I think it's gaining momentum as it goes.

Regards,

Alex