Subject: Re: Questions about our XML grammar
From: Paul Rohr (paul@abisource.com)
Date: Tue Jan 09 2001 - 17:05:14 CST
At 06:31 AM 1/9/01 -0800, Leonard Rosenthol wrote:
>I'm working on a new project that involves reading AbiWord files, and
>in looking over some output from Abi (so that I could then write the
>code to process it),
Cool!
>I noticed a few things that I'd like to suggest
>be changed and I might even submit the patch to do it if no one
>objects.
OK, now we learn what it takes for me to delurk (briefly). If a little
design feedback from me can result in Leonard's first patch, then I'll
bite. :-)
>* No tags/attributes for page sizes and/or margins. I would suggest
>that these are probably either abiword or section attributes.
Definitely needed. Should be section props.
>* Is there a reason we call it "props" rather than "style"? Yes, it
>is our properties, but it's also similar to CSS style values.
Two reasons.
1. We didn't want to suggest full CSS compatibility everywhere. IIRC,
we've always talked about how our file format uses "CSS-like" properties to
help make that clear. Wherever possible, we do reuse existing CSS property
names and semantics (to avoid surprises), but we've taken license to add our
own properties for WYSIWYG support where needed.
2. More specifically, we don't use the CSS mechanisms for binding
properties to content. Instead we've reserved the style attribute for
referencing named styles. For more details, see:
abi/test/wp/Styles.abw
In short, the difference here is deliberate, and not gratuitous.
>* The "line-height" property for <p> is tracked as a multiple of
>something I'm guessing the default line height), rather than the more
>common fixed value for "leading".
Good guess. As the parsing logic in fl_BlockLayout::_lookupProperties()
indicates, we also support fixed dimensions with "At Least" or "Exactly"
semantics. I'm not sure how thoroughly these more advanced spacing policies
have been tested, though.
>* The "color" property for <c> should have a leading # in front of
>the size hex values to delineate it as a hex value (as per CSS spec).
>That way we could also support other types of color specifications
>such as names ("aqua", "black", etc.) or other color spaces (CMYK,
>gray, etc.).
IIRC, when this was originally implemented way back when, the executable was
*much* smaller, and nobody wanted to bloat it by adding all of the
additional lookup tables required for other colorspaces. (Translation -- we
were in a hurry and nobody wanted to type it all in.)
I'm not sure this additional color flexibility is really needed in a simple
WYSIWYG word processor, but I'd have no objections to parser (and/or
exporter) patches here which didn't break file format compatibility.
>* Subscript and Superscript are handled with the "text-position"
>property, but that seems pretty limiting since it doesn't provide for
>control over baseline shift percentage. Could we replace that value
>with a float (or int) specifying how much to baseline shift by (and
>it should support both fixed values as well as percentages - eg. 5,
>-5, 50%).
AFAIK, the existing implementation is just (barely) simple enough to support
basic WP functionality. For more details, consult cvsblame. ;-)
I have hazy memories of design discussions which pointed out that,
historically, there have been two different formatting models for sub/sup
behaviors in the evolution of Word's file format(s).
Obviously a clever implementation which could handle all that mess would be
nice, especially if it doesn't hork up the dialogs for controlling this
behavior.
>* The columns property tells one how many columns, but nothing about
>their sizes/margins.
With the exception of the column-gap property (settable via Jeff's funky
ruler widget), I suspect that's still all hardwired.
Given that the 1.0 Columns dialog didn't need more complex properties, the
field is wide open for new proposals for additional properties here.
However, IIRC, the hard work comes in *using* any such properties. Last
time I checked, the existing column model in the formatter was deliberately
simplistic, and most "advanced" columns dialogs I've seen are butt-ugly. If
someone's looking for a meaty post-1.0 project, this could be interesting
work.
Paul
This archive was generated by hypermail 2b25 : Tue Jan 09 2001 - 17:24:34 CST