[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] review ODF 1.2 specification draft - chapter 18,attributes in fo namespace
Dear TC members, below you find Patrick's reply to my ODF 1.2 draft 7 review comments from mid of November 2008. Unfortunately, we, the TC, did not answer/reply to any of Patrick's comments/questions including myself. I think it is a good time now to come back to reviewing our ODF 1.2 specification draft in order to finish it. Thus, comments/questions/clarifications are welcome. You will post mine as soon as possible (hopefully before today's ODF TC call). Best regards, Oliver. Patrick Durusau wrote: > Oliver, > > Thanks for the comments! > > Note that only some of these answers will be reflected in the draft I am > posting tomorrow. I passed it to Michael before I finished reviewing > these comments. I expect to be dropping new versions every two weeks > until we have all the Sun comments incorporated and proofed. > > I invite everyone to review these responses but I want to call your > attention to some specific items: > > 1. 18:402 fo:background-color - in particular the question about > disabling images for cell, row, table > > 2. 18:408 and 18.409 - objection to deprecating these attributes? > > 3. 18.411 the separator line question > > 4. 18.415 - suggestions for the third editorial note? > > 5. 18.421 - changing default value or value space? Which one? > > 6 18.429 fo:margin-bottom - note question about whether we are > announcing a limitation to common styles > > And see the question about header/footer. I don't have any particular > position on this but we do need to be clear about what we intend to > restrict. > > 7. 18.430.1 fo:margin-right - see the question about removing the > description of margins in tables. > > There are a number of attributes that follow with the comment that XSL > 1.0 references were missing from ODF 1.1. I don't know if these were > intentional or not. Can someone comment on that? > > 8. 18.434 fo:min-height - rule on svg:height and fo:min-height? > > Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote: >> Dear TC members, >> >> I have reviewed the attributes in the fo namespace in chapter 18 of our >> current ODF 1.2 specification draft. >> >> Here are my comments: >> - General >> -- I am not sure, if it is good to have only the reference to XSL for >> attributes in fo namespace. Below, you will find some comments to >> include some sentence about the attribute's purpose. After given such >> comments to the first reviewed attributes I omit them for the rest and >> write down this general comment. I think we should decide, if a >> reference to XSL is enough for such attributes or if some text about the >> purpose of such attributes for ODF should be added. >> > Sure, we could make 18:401 a section that treats fo attributes > generally, whether we made all the fo attributes as children of such a > section or not. I suspect having a section would be clearer but that > should be easy enough to do if we decide to go in that direction. > > If we create such a section, that gives us an easy place to treat issues > such as the non-use of inheritance as defined by XSL. >> - "18.402 fo:background-color" >> -- Replace the two "ref-element-..." text snippets by the corresponding >> reference. > Done. > > Actually, I need to split this out as the semantics of the attribute > vary depending upon the element where it occurs. > > For example, one paragraph, it switches off <style:background-image> but > that isn't the case for its use with style:text-properties. > > Sigh. Modulo that change my responses to the comments follow: >> -- Reference to XSL is missing. The former reference to XSL can be found >> in the ODF 1.2 specification draft 6 in sub chapters 16.4.37 and 16.5.23 > Done. >> -- 3rd paragraph: Integrate that this statement for paragraph also holds >> for page, header, footer and section. > Suggest: > > "This attribute sets the background color for a footer, header, page, > paragraph and section. If the value is set to transparent, it switches > off any background image that is specified by a > |<style:background-image>| . 16.6" >> >> -- 4th paragraph: Integrate that this statement for table and cell also >> holds for row. > Suggest: > > "Together with the |<style:background-image>| element, this attribute > specifies the background properties of a cell, row or table. " > > Question: Is there a difference between paragraphs 3 and 4 other than > the elements being described? In other words, if for cell, row and > table, the value is transparent, doesn't that disable the image > specified by <style:background-image> for cell, row, and table? >> -- 5th paragraph: Indicate that this statement holds for table, cell and >> row. > I am not sure the indirection of fill attributes via <style:style> is > really usefully reported by: > > "Fill formatting properties can be used instead of this attribute for > enhanced table row and table cell background fill styles. If a value for > a |draw:fill| attribute is provided, then a background image that is > specified by a |<style:background-image>| element and a background color > that is specified with the |fo:background-color| attribute are switched > off." > > Even if I add table to this paragraph. > > Can you suggest a better location for this statement? Or perhaps saying > something more explicit around the use of <style:style>, etc.? >> -- Include paragraph which contains statement for frame regarding >> background according to ODF 1.2 specification draft 6, sub chapter >> 16.27.18 > Ok, but could we say, I suppose in some future version, say that the > <style:style> element reference for *any* element has all of its style > properties? Of any sort? >> -- Generated section from schema contains twice the statement about the >> elements the attribute is used with. > I will ask Michael about that. >> >> - "18.403.1 General" >> -- content of first bullet item has to be <style:graphic-properties> > True, but that also makes the relationship to the borders for frames > indirect (see your next point). Still, the correction should be entered. >> -- Probably, we can remove the bullet list and replace it by some text >> like "... specify border properties for page, header/footer, paragraph, >> cell and frame." Information about the elements the attributes may be >> used with is already given in the generate section. > True. But if we change that here, we need to systematically make that > change across the standard. > >> >> - "18:404 fo:break-after" and "18.405 fo-break-before" >> ad Ed. Note: I do not think that we support value "inherit". The value >> was not in the schema fragments in the ODF 1.2 specification draft 6. >> Thus, I think we should add this to the paragraph, which already state >> that we do not support value "odd-page" and "even-page". >> > We don't support the FO inheritance model anywhere so that could be > stated for all FO attributes. And then make specific statements values > not supported for particular attributes. > > That would substantially change the numbering so we need to do that > prior to a public draft if at all possible. >> - "18.406 fo:clip" >> -- I have no answers for the two editor notes. >> -- It seems that we also does not support value "inherit". >> --> a lot of questions/remarks. Thus, this attribute sub chapter is >> somehow in status "red" from my point of view. > OK, does anyone disagree with my reading of the excluded attribute values? >> >> - "18.407 fo:color" >> -- Please include a sentence like "The fo:color attribute specifies the >> foreground color of text." >> -- ad Ed. Note 1: I do not know, if we want switch to XSL 1.1. But, if >> we switch, all XSL references need to be adjusted. >> -- ad Ed. Note 2: Yes, it seems that we do not support value "inherit". >> Thus, we have to state it explicitly. > The XSL reference cites CSS2 to say that this attribute sets the > foreground color of text content. Other than convenience, is there > another reason for making this statement here? > > Reasoning that all the standard need do is state the rule as briefly as > possible, such as by citation of another standard. If I were creating a > version of the standard for implementers (which would be far longer than > the normative standard) I would include all manner of material from > other standards, rather than simply using references. >> >> - "18.408 fo:column-count" and "18.409 fo:column-gap" >> I have got no solution for the remarks in the editor's notes. > OK, for backwards compatibility (this release only), does anyone object > to deprecating both of these attributes? We really should not abuse the > FO namespace this way. > > The other part of the solution will be to declare other attributes that > should be used in 1.2 for these purposes. >> >> - "18.410 fo:country" >> -- Relation to fo:language: fo-country may be ignored if it is not >> specified together with fo:language attribute. >> -- ad editor's note: Yes, it seems we do not support value "none" and >> "inherit". Thus, we have to state it explicitly. >> -- Include a paragraph, which states that this attribute specifies the >> country of a text for its usage in element <style:text-properties>. > Don't we already have a cross-reference to this attribute under > <style:text-properties>? > > Isn't the question what attribute(s) establish locale? And the answer to > that is fo:country and fo:language? > > Not disagreeing with the suggestion but thinking that we need to cover > locale for all the cases where it is relevant and not on an attribute by > attribute or element by element basis. >> -- Include a paragraph, which describes that fo:country and fo:language >> are also used to further define sorting algorithms - see ODF 1.2 >> specification draft 6, sub chapters 7.8.1, 7.8.1.8 and 15.10.3.3 - for >> its usage in elements <text:alphabetical-index-source> and >> <text:bibliography-configuration>. >> > This is my point about the local information again. > >> - "18.411 fo:end-indent" >> -- Include statements (taken from ODF 1.2 specification draft, sub >> chapter 16.7.4.2). Probably, we should include this information at >> element <style:column>: >> --- that this attribute specifies the right space of a column, >> --- that this attribute together with the left space (fo:start-indent) >> of the following column corresponds to the gap between these columns and >> --- that the width of an existing separator line between these columns >> is included in these spaces. >> -- Question: is the reference to XSL ok? We did not have it in ODF 1.2 >> specification draft 6. >> > Ah, because we are not describing all "block-level formatting objects." > (as does XSL) OK, that makes sense. > > On the separator line I assume you mean: > > "If a columned area contains a separator line between columns, the space > that is occupied by the line is contained within the left and right > spaces and therefore is not added to them." > > OK, so: "A separator line may appear in the space between columns that > is specified by the fo:end-indent and fo:start-indent attributes. The > width of the line is not added to the value of either attribute." > > So, does that space operate as a constraint on the separator line? That > is it cannot be bigger than that space? Must it be centered on that > space or is other placement possible? >> - "18.412 fo:font-family" >> -- Include statements (taken from ODF 1.2 specification draft 6, sub >> chapter 16.4.14) >> --- that the attribute specifies the font family of a text and >> --- that this attribute can be used instead of the style:font-name >> attribute, but usage of style:font-name is recommended. >> -- Generated text contains twice the statement about the element with >> which the attributes may be used. >> > Shouldn't we simply deprecate this attribute? And if we do, do we really > want to make it any easier to use? > > My sympathies are for taking your advice on the font family, etc., that > is to fully describe even deprecated material but that may simply > encourage it use. > > I have no axe to grind one way or the other. > >> - "18.413 fo-font-size" >> -- 3rd paragraph does not belong to this attribute - it more belongs to >> fo:font-family. > Yes. >> -- Information about values given in ODF 1.2 specification draft 6, sub >> chapter 16.4.19 is completely missing. >> -- We should explicitly state which attribute values from XSL we do not >> support. >> -- I do not think that this attribute should be deprecated. >> > You mean such as: > > "The value of these attribute is either an absolute length or a > percentage as described in §7.8.4 of [XSL]. In contrast to XSL, > percentage values can be used within common styles only and are based on > the font height of the parent style rather than to the font height of > the attributes neighborhood. Absolute font heights such as |medium|, > |large|, |x-large|, and so on, and relative font heights such as > |smaller|, and |larger| are not supported." > > I think it needs cleaning up but yes you are correct, that needs to be > added back in. > > The other paragraphs, which are references to other font size attributes > are more problematic. > > The organization of the document to split out the attributes into > individual sections has a cost. That is that every attribute, even if > intimately related to another, has its own separate existence and > description. > > My suggestion would be for cases like this one, where the reader is > likely to want information about other fonts (we have a similar > situation) is to create Notes (this means non-normative text) that > directs their attention to the other material. > > My take is that solves the need for related information and at the same > time preserves the ability to single out any particular element or > attribute for additional information or annotation. >> - "18.414 fo:font-style" >> -- We should explicitly state which attribute values from XSL we do not >> support. >> >> - "18.415 fo:font-variant" >> -- ad 1st editor's note: see my comment above - 18.407 >> -- ad 2nd editor's note: not supported values from XSL should be >> explicitly named. >> -- ad 3rd editor's note: I have no solution. --> status "red" >> > Does anyone else have an opinion on the 3rd editor's note? >> - "18.417 fo:height" >> -- Include statement that this attribute specifies the height of the >> bullet image in a certain list level definition. >> -- ad editor's note: >> --- explicitly name not supported XSL attribute values. >> --- I do not know, if this attribute is only used for specifying the >> size of a bullet image. Action item for me: check it in OpenOffice.org. >> > Well, in draft 6, 16.12.6 says that the size of the image is specified > by this and fo:width. Maybe used more broadly but I am just going by the > language in the text. >> - "18.418 fo:hyphenate" >> -- ad editor's note: >> --- Yes, we have to explicitly state that we do not support value >> "inherit". >> --- No answer from my side to the other questions in the editor's note. >> I think these question are also for the other fo:hyphenation-... >> attributes. Right? >> > Yes, other fo:hyphenation attributes. >> - "18.419 fo:hyphenation-keep" >> -- Explicitly state that we do not support values "column" and "inherit". >> >> - "18.420 fo:hyphenation-ladder-count" >> -- Explicitly state that we do not support value "inherit". >> >> - "18.421 fo:hyphenation-push-char-count" >> -- Default value can not be 0, because the value type of this attribute >> is "positiveInteger", which does not include 0. XSL states that its >> value is of type "integer" and that negative and non-integer values are >> mapped the nearest integer greater than 0. >> Possible solutions: >> - change type of attribute to "nonNegativeInteger" or >> - change default value. >> -- Explicitly state that we do not support value "inherit". >> > OK, more questions: > > 1) Changing the default value has the greatest chance of causing > backwards compatibility issues. Yes? > > 2) If #1 is yes, I asssume we can use nonNegativeInteger and leave the > default alone? > > I prefer the solution with the least impact on existing applications but > don't have a feel for that issue. >> - "18.422 fo:hypenation-remain-char-count" >> -- [the same as for fo:hypenation-push-char-count - see above] >> >> - "18.423 fo:keep-together" >> -- Please state that this attribute is used for paragraphs and table >> rows. >> -- Yes, state that we do not support value "inherit" and integer values. >> > Because narrower than XSL? > > Isn't that already stated by it only appearing on row and paragraph > element elements? > > Still, I think your point that our divergence from XSL should be called > out. >> - "18.424 fo:keep-with-next" >> -- Reference to XSL is wrong. It has to be "§7.19.4", not "§7.9.14". >> > Yes. Thanks! >> - "18.425 fo:language" >> -- Yes, we do not support values "none" and "inherit". >> -- The "corresponding" comes in due to copy-and-paste from original >> section, in which also style:language-asien and style:language-complex >> are specified. IMHO it can be removed. Thus, fo:country and fo:language >> "go together". The same is hold for style:country-asien and >> style:language-asien. And for style:country-complex and >> style:language-complex, too. > So, delete: "This attribute may be ignored if it is not specified > together with a corresponding |fo:country| attribute." > > Yes? > > I was am planning on a joint treatment of fo:language and fo:country as > locale. Just need to find the right place for it. >> -- Include a paragraph, which describes that fo:country and fo:language >> are also used to further define sorting algorithms - see ODF 1.2 >> specification draft 6, sub chapters 7.8.1, 7.8.1.8 and 15.10.3.3 - for >> its usage in elements <text:alphabetical-index-source> and >> <text:bibliography-configuration>. >> > Locale issue. >> - "18.426 fo:letter-space" >> -- Yes, we do not support values "space" and "inherit". >> >> - "18.427 fo:line-height" >> -- 2nd setences of 1st paragraph should be removed. It is the same as >> the 2nd paragraph. >> -- Yes, we do not support values "number", "space" and "inherit". >> > Delete: "A value of |normal| disables the effects of > |style:line-height-at-least| and |style:line-spacing| ." >> - "18.428 fo:margin" >> -- Yes, we should state that we do support only one value, which can be >> a length or a percentage. A percentage is relative to the parent style's >> margin - like it is for the other fo:margin-... attributes. >> >> - "18.429 fo:margin-bottom" >> -- Yes, we do not support value "auto" and "inherit". >> -- Yes, in general we do not support value "inherit" from XSL >> attributes, but for value "auto" I do not think this is true - see >> fo:keep-together and fo:hyphenation-keep. > Yes. >> >> -- For a percentage value we should state that the bottom margin value >> is the given percent value of the parent style's bottom margin value. > With the caveat that is true within a common style, or at least so says > the prior draft. Is that a limitation/constraint? >> -- Information is missing that a percentage value is not supported for >> <style:graphic-properties> - see sub chapter "16.27.5 Top and Bottom >> Margins" of ODF 1.2 specification draft 6. > Sorry, 16.27.5 in draft 6 says: > > "The |fo:margin-top| and |fo:margin-bottom| attributes determine the top > and bottom margins to set around a frame. See section 16.5.20. > Percentage values are not supported." > > I searched on style:graphic-properties and did not find the limitation > you mention. >> -- Information is missing that for page footers attribute >> fo:margin-bottom is ignored - see sub chapter "16.3.2 Margins" in ODF >> 1.2 specification draft 6. >> > Yes, but that text says: "Bottom margins are only evaluated for headers, > top margins only for footers." > > Since this can appear in <style:paragraph-properties> (since paragraph > elements appear in headers and footers) do we mean a processing > constraint, i.e., if you see fo:margin-bottom being applied in a > paragraph in a footer element ignore it or is this a validity > constraint? That is to say the XML itself is invalid? >> - "18:430 fo:margin-left" >> -- Information is missing that a percentage value is not supported for >> <style:graphic-properties> - see sub chapter "16.27.5 Left and Right >> Margins" of ODF 1.2 specification draft 6. > I don't see that restriction. > > In 16.27.5, simply says that percentage values are not supported around > frames. > > Ah, ok, I ran it to ground. What you mean is that when the prior draft > said "not supported for frames" it was actually stating a restriction on > <style:graphic-properties>. Rather indirect. ;-) > > I will restore it but stated more directly. >> -- Percentage value for section also does not make sense - see sub >> chapter "15.7.2 Margins" in ODF 1.1 specification. Or do we changed this >> for ODF 1.2 - I did not find a corresponding proposal. > I don't have any notes suggested that this was changed. > >> >> -- The second and third paragraph should be removed. They should be >> integrated into element <style:list-level-label-alignment>. For >> <style:list-level-lable-alignment> percentage values does not makes >> sense and need to be excluded. -> I have given me an action item to >> provide the corresponding text. > Agreed. >> -- 5th paragraph about fo:text-indent can be removed in my opinion - it >> is already present at attribute fo:text-indent. >> -- In last paragraph the information about right margin in tables should >> be removed. >> -- For a percentage value we should state that the left margin value is >> the given percent value of the parent style's left margin value. > Yes. >> >> -- Question to the schema experts: Can the schema assure certain value >> types in certain elements? Than we do not have to state in prose that in >> certain elements percentage values are not supported. >> > Well, sure, you simply define an attribute or attribute group with the > value restrictions that are desired. The problem here is that we use a > reference to another definition of the attribute and restricting that > value set. There are schemas where that can be done but I haven't looked > closely at XSL with that in mind. > > >> - "18.430.1 fo:margin-right" >> -- This sub chapter should be a sub chapter of chapter "18 Attributes". > Yes. >> -- Information is missing that a percentage value is not supported for >> <style:graphic-properties> - see sub chapter "16.27.4 Left and Right >> Margins" of ODF 1.2 specification draft 6. > Yes, but see my suggestion about restating this restriction more > directly under fo:margin-left >> -- Percentage value for section also does not make sense - see sub >> chapter "15.7.2 Margins" in ODF 1.1 specification. Or do we changed this >> for ODF 1.2 - I did not find a corresponding proposal. > Nor did I. >> -- 3th paragraph about fo:text-indent can be removed in my opinion - it >> is already present at attribute fo:text-indent. >> -- In last paragraph the information about left margin in tables should >> be removed. > Why? > > Has the behavior we defined changed? >> -- Yes, list item does not have a right margin via its list level >> properties, which are applied via the list style. >> > OK. >> - "18.431 fo:margin-top" >> -- Yes, we do not support value "auto" and "inherit". >> -- For a percentage value we should state that the top margin value is >> the given percent value of the parent style's top margin value. >> -- Information is missing that for page headers attribute fo:margin-top >> is ignored - see sub chapter "16.3.2 Margins" in ODF 1.2 specification >> draft 6. >> > See my comment on bottom margins above. >> - "18.432 fo:max-height" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.14.6. >> >> - "18.433 fo:max-width" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? >> > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.14.7. > >> - "18.434 fo:min-height" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.14.8. >> -- 1st paragraph should also state that it specifies the minimum height >> of a text box. >> -- It should also be stated that the attribute specifies the minimum >> height of a header or a footer - see sub chapter "16.3.1 Fixed and >> Minimum heights" in ODF 1.2 draft 6 >> -- Ad editor's note: It is meant that svg:height specifies the fixed >> height for a header or footer, while fo:min-height specifies the minimum >> height for a header or a footer, in my honest opinion. >> > Well, but for text box (9.3.1 in ODF 1.1) we say that fo:min-height > overrides the svg:height. > > Isn't that inconsistent with saying that svg:height specifies a fixed > height and fo:min-height sets a minimum height? > > At least with the override language, there really is only one height if > both are present. Yes? > > Well, draft six unhelpfully says svg:height and fo:min-height set fixed > or minimum height for a header or footer. That implies there is a choice > but it doesn't say which one. > > Suggestions? > >> - "18.435 fo:min-width" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? >> -- Ad editor's note: svg:height specifies the height of a text box, >> while fo:min-width specifies the minimum width of a text box, in my >> honest opinion. >> > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.14.9. >> - "18.436 fo:orphans" >> -- We do not support value "inherit". >> -- We strict the attribute for paragraph orphans. >> >> - "18.437 fo:page-height" >> -- We only support value type "length" >> >> - "18.438 fo:page-width" >> -- We only support value type "length" >> >> - "18.439 fo:padding" >> -- We only support one value of type "NonNegativeLength" >> >> - "18.440 fo:padding-bottom" till "18.443 fo:padding-top" >> -- We do not support value "inherit" >> >> - "18.444 fo:space-after" and "18.445 fo:space-before" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? >> -- We restrict its usage to a column. >> -- We do not support value "inherit". >> > I don't know if it why these were omitted. To correct for XSL 1.0, the > citation would be to 7.10.6 and 7.10.5, respectively. >> - "18.446 fo:start-indent" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? >> -- We restrict its usage to a column. >> > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.10.7 > > Note since we do restrict to column and not all block-level formatting > objects. >> - "18.447 fo:text-align" >> -- Include statement that this attribute is used for alignment of >> paragraphs and the alignment of list labels. > It already treats list labels. I take it that you want a more general > statement about paragraphs and then the list label material. Works for me. >> -- Move information of 2nd paragraph, the following enumeration and the >> 3rd paragraph to element <style:list-level-properties> -> I have given >> me an action item to provide the corresponding text. > OK. >> -- Add information to 4th paragraph that this is hold for the alignment >> of paragraphs. >> > OK. >> - "18.449 fo:text-indent" >> -- ad editor's note: I will provide some text about it for element >> <style:list-level-label-alignment>. Here we should only add at the end >> of the 1st sentence the text "or a list item". >> > OK> >> - "18:451 fo:text-transform" >> -- Question: Is it really deprecated? I did not find the corresponding >> proposal. >> > No, my mistake. It cannot be used with| fo:font-variant, if it is, the > result is undefined. | >> - "18.452 fo:widows" >> -- We do not support value "inherit". >> -- We strict the attribute for paragraph widows. >> >> - "18.453 fo:width" >> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was >> the reason to include it? Was it intention not to have it or was it a >> defect? >> -- We restrict its usage to the image of the list label, as far as I can >> see. >> > I don't know if it why it was omitted. To correct for XSL 1.0, the > citation would be to 7.14.12 >> - "18.454 fo:wrap-option" >> -- I am not familar with this attribute. Thus, the status of this >> attribute is somehow "red". >> > Comments on this one would be most welcome. > > Deeply appreciate the comments! > > Hope you are at the start of a great day! > > Patrick > -- ======================================================================= Sun Microsystems GmbH Oliver-Rainer Wittmann Nagelsweg 55 Software Engineer - OpenOffice.org/StarOffice 20097 Hamburg Germany Fax: (+49 40) 23 646 955 http://www.sun.de mailto:oliver-rainer.wittmann@sun.com ----------------------------------------------------------------------- Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering ======================================================================= Oliver-Rainer Wittmann (od) - OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]