Re: [office] review ODF 1.2 specification draft - chapter 18, attributesin fo namespace

[Patrick Durusau <patrick@durusau.net>]

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

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)