Re: [office] Style properties questions/requests

[Michael Brauer <michael.brauer@sun.com>]

Hi David,

David Faure wrote:
> 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.

 From the XML point of view, I agree. The problem with seperate values 
is inheritance: Individual properties can be changed independently of 
each other within styles. This means, that one can specify in one style 
an "single dotted" underlining, and in an derived style "double bold". 
If there are seperate attributes, the resulting style would be "double 
dotted bold". If there is a single attribute, the resultling style would 
  "double solid bold", provided that "solid" is the default line style. 
So whether it is reasonable to have seperate attributes from my point of 
view depends on whether it is reasonable to specify the values of these 
attributes independently.

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

For borders, XSL-FO combines these two attributes in a single 
"fo:border-style". However, fo:border-style supports less values.

> * text-underline-thickness: "default", "bold"

What about "text-inderline-width=(medium|thick)". This would be similar 
to "fo:border-width".

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

"small-wave" is existing the the OOo text engine, but mapped to "wave" 
at the moment.

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

Yes, for RTL languages right-alignment is specified in the Standard 
style. In addition to this, there are two buttons in the toolbar to 
switch between RTL and LTR. They also change the alignment.

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

No, ee always changed the namespace to "style" in this case. So I 
suggest that we either rename fo:text-align to style:text-align and add 
the "automatic" value, or add a separate attribute. However, what 
happens if the paragraph has a numbering applied? Is the first character 
in the generated number or in the paragarph's text.

The benefit of two attributes in fact would be that one could specify 
the "automatic" value together withe value that is really applied. This 
would simplify transformations in fact.


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

I agree. This seems not to be 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.

It exists in the DTD, but unfortunately seems to be missing in the 
specification document.

The attribute is

<!ATTLIST style:properties style:writing-mode 
(lr-tb|rl-tb|tb-rl|tb-lr|lr|rl|tb|page) "lr-tb">

It is nearly the same as fo:writing-mode, except that fo:writing-mode 
does not support "tb-lr" and "page". "Page" has only a meaning if 
"writing-mode" is applied to a paragraph. The meaning of "page" is to 
take the value from the page a certain paragraph is part of.

In section A.1 (http://www.w3.org/TR/xsl/sliceA.html#writing-mode-add) 
of the XSL-FO specification "tb-lr" appears as an additional value for 
fo:writing-mode. Since the value of "page" also matches "inherit" in 
XSL-FO, we might consider to use "fo:writing-mode" instead of 
"style:writing-mode".

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

Daniel is working on an updated specification.

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

OpenOffice.org and at least one other office suite support specifying 
different font attributes for the different regions (wetsern, cjk, 
complex) of the UNICODE character set. The problem however is that some 
UNICODE characters are "weak", that means, they get their region from 
the characters in front and behind it, so even looking at a single 
UNICODE character is not sufficient to get the correct range.

Since this makes XSLT transformation difficult, we might consider to add 
  an element to the specification that contains the script type that is 
active like

<text:p><text:script text:type="western">[western 
text]</text:script><text:script="cjk">[japanese 
text]</text:script></text:p>.

As an alternative, we might also try to somehow make use of automatic 
styles and the classes we added recently. The idea is to have an 
attribute that specifies the font value that is actually used in 
addition to three for western, cjk and complex characters. For every 
text portion of a certain script type, one may add and reference an 
automatic style that contains the "actual" font value in use. However, 
office suites will ignore these "actual" font values and only use the 
western, cjk and ctl values.

The additional automatic style is required,  because the asian and 
complex font properties do exists in styles as well, and one will only 
know which property has to be used if the style is applied to some text.

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

I'm not familiar with these topic, so I suggest to ask in the OOo i18n 
project mailing list for further information.

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

Best regards

Michael