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

[Craig Ringer]

On Wed, 2005-06-22 at 19:09 -0600, Oleksandr Moskalenko wrote:

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

We can get away with supporting multiple units. Initially we'd just
convert on input, but later on we could transition over to proper
measurement classes that would let that conversion be done only at the
last possible moment.

I've done that in Python, and it's really no big deal. You'd do it the
same in C++. Converting the existing codebase would be time consuming,
but not that hard as it could be done progressively.

> I was told by Craig B. that internal calc is done in pts already.

Yep.

> We have to
> have a thorough discussion about it when I get back from a trip in a couple of
> days.

Sounds like a plan. I'll hack together some info on the wiki to serve as
a starting point.

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

OK. The canvas is currently purely an implementation artefact - its
origin is (0,0) of the QScrollView. IIRC the co-ordinates of the pages
can change depending on the scratch space size and page arrangement.

If we're going to use arrange objects relative to the canvas as a whole,
the canvas co-ordinate space will probably need to be clearly defined
in a way that doesn't rely on implementation details of the Scribus GUI,
and in a way that handles users wanting to rearrange pages without
breaking object positioning.

Ugh.

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

Ah, cool. Works for me, then.

> > >                <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?

One of your later posts contained a demo of char styles, which was the
most obvious candidate. There are however potentially a number of other
uses. One that comes to mind is marking words for inclusion in an index.
PDF annotations might well be another (though some of those would span
multiple pars). I'm sure there are more I haven't thought of.

Marking a range of text for inclusion in the table of contents and
providing the ToC heading and level would be another one. We can do that
at the frame level now thanks to cbradney, but being able to extend that
down to text within a frame would potentially be very useful especially
as long linked frame performance and control over text formatting in
frames improves.

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

Ah, OK. No worries then. So long as we carry the page format name
somewhere in the document its self so someone who hasn't set that
particular page size up in their copy of Scribus can tell what it is and
is called.

>  We'll have to merge the pdfoptions and preferences dtds into
> the main one soon, too, at least to avoid confusion.

Agreed. Preferences has a pretty simple markup with most stuff done as
attributes and CDATA, so it'll be short and simple (but probably won't
validate particularly usefully).

--
Craig Ringer