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.
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. > <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"? > <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) ? 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. > </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". > <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? > </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. > <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
