OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Style properties questions/requests


On Friday 15 August 2003 15:30, Michael Brauer wrote:
> Hi David,
> 
> David Faure wrote:
> > Text properties:
> > 
> > style:text-crossing-out (3.10.6) doesn't have support for stylelines (solid, dash, dot, dashdot, dashdotdot)
> > KOffice supports crossing out text with various style of lines.
> > 
> > style:text-underline (3.10.22) should separate the number of lines (single/double) from the style of the lines (dotted etc.).
> > This allows more combinations, like double-dotted, etc.
> > The presence of all the bold-* values also suggests that bold should be separated.
> 
> Both sounds reasonable. Do you think we should have seperate attribute 
> or should only separate the values (like "single dotted bold")? 
Personnally I would prefer separate attributes. XML is about separating attributes,
not about implementing different parsers for each attribute content.

> We might  also consider to use the same values for both attributes.
Yes.

Let's try to define this more precisely.

What about the following attributes, with their possible values:
* text-underline-type:  "none", "single", "double"
* text-underline-style: "solid", "dash", "long-dash", "dot", "dot-dash", "dot-dot-dash", "wave", "small-wave"
* text-underline-thickness: "default", "bold"
* text-underline-color already defined (3.10.23)

This leads to more possible combinations than the current OO format,
and requires less possible values in all.

And the same with "strikeout" instead of "underline" in the attribute names,
for strikeout. 
Ah, or "crossing-out" if you prefer, but "text-crossing-out-type" gets a bit long.

What's "small-wave" BTW? I can't find it in the OOWriter GUI, there's only
wave, bold wave and double wave.

> > Paragraph properties:
> > 
> > fo:text-align (3.11.4) doesn't seem to have "auto" (for bidi text). This is used
> > in KOffice to mean that the alignment of the paragraph depends on whether
> > it starts with a RTL character. Apparently this is a common feature for RTL users,
> > to have the alignment and the direction of the paragraph automatically detected
> > that way.
> 
> One might do so, but since XSL does not have a value for this, we would 
> have to change the namespace. Instead we might also add a new attribute 
> that only specifies that the alignment should be derived from the text 
> and leave the fo:text-align unchanged.

Hmm, I see. How do Hebrew users use OOWriter BTW? Do they specify 
right-alignment as part of their Standard style? It is obviously more convenient
to have the paragraphs auto-align automatically depending on which kind
of character one types into them. This value for the alignment attribute is
mostly useful for styles of course, not for actual paragraphs.

I'm ok with the solution of having another attribute for this, although it seems
a bit overkill (hasn't it been done in other cases, to extend an FO attribute
with a new possible value?).
Another solution would be that when there is no text-align attribute in a style
then it defaults to this "auto" behavior (at least in KWord). But with inherited
styles this isn't very convenient.

In fact I'm also missing the attribute for the direction of the paragraph (which
is another notion - the paragraph can be left aligned and have a global direction
of right (RTL) or left (LTR), this is used to know how navigating with the 
caret in the paragraph should work).
It is apparently standard (in Windows, and now in Qt too) that Ctrl+LeftShift switches
to left and Ctrl+RightShift to right.
IIRC this is the "dir" attribute for <parag> in HTML.

> > style:tab-stop (3.11.10) 
> > I found out that common values for leading-char (in OOo) are '.', '-' and '_'
> > (this should be documented btw).
> > In KOffice we are currently using line styles instead (none, dots, plain line, dash,
> > dash-dot, dash-dot-dot), but this indeed misses something like '-', i.e. at 
> > the middle vertically (all the lines are currently drawn at the baseline).
> > Does anyone know what other word processors use? If they all use characters
> > I guess I'll switch to that, otherwise we might need something a bit more flexible...

We could use something like text-underline-style above, but it misses something
for '_', and of course wave-looking tabs would be rather strange :)
(still to be investigated in other WPs)

> > fo:keep-with-next/style:keep-with-next (3.11.31) Please fix the documentation
> > if it hasn't been done yet, since Daniel said:
> > "It's always fo:keep-with-next. The documentation is wrong; we 
> > don't use style:keep-with-next anywhere.
> 
> Thanks for reminding us that this is still wrong in the specification.

Is there a version of the specification somewhere that is being updated
with the changes decided here? Or will that only be done in the end,
from the various meeting minutes?

> A similar error occured for the various fo:*-asian and fo:*-complex 
> properties that in fact have to be in the style namespace.

I alos don't know what to do with those - at least with Qt I don't need to
specify another font depending on the type of characters (it sorts it out
by itself).

> > style:line-break (3.10.37) (apparently this should be moved to paragraph properties)
> > What's strict linebreaking? The documentation only says it can be normal or strict...
> 
> In some asian languages there are so called "forbidden" characters that 
> must not appear at the beginning or the end of a text line. The 
> "style:line-break" attribute specifies whether a line break is allowed 
> at any position or only at positions where the resulting lines will not 
> start or end with an "forbidden" character. 
OK.

> The list of forbidden  
> characters is language dependent and normaly supplied by the same "i18n" 
> framework that evaluates possible hyphen positions.
[Interesting - we use libhnj for the hyphen positions, which comes from OO.
Do you know which method of libhnj provides this? It's not in my copy, but
maybe it got simplified before being imported into KOffice].

> In the OpenOffice.org application the forbidden character lists can be 
> edited. If it has been edited, it is stored in the application specific 
> settings of the document. However, one can also specify whether the 
> forbidden characters shall be loaded together with a document or whether 
> the defaults should be used in any case. This means that they are 
> somehow comparable to personal dictionaries that are used for 
> hyphenation, except that they are never stored in a document.
OK.

> The style:text-background-color attribute can from my point of view be 
> removed, because a differentiation between text and paragraph 
> backgrounds is existing already since we replaced the <style:properties> 
> element with <style:text-properties> and <style:paragraph-properties>.
Yes.

-- 
David FAURE, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]