Bug 96066 - ODF does not allow negative values in attribute fo:padding, but LO writes negative values
Summary: ODF does not allow negative values in attribute fo:padding, but LO writes neg...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: odf odf_validation
Keywords:
Depends on:
Blocks: ODF-export-invalid
  Show dependency tree / graph
 
Reported: 2015-11-25 15:32 UTC by Regina Henschel
Modified: 2023-12-11 12:08 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Example produced with LO 5.1 (328.10 KB, application/vnd.oasis.opendocument.graphics)
2015-11-25 15:32 UTC, Regina Henschel 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2015-11-25 15:32:45 UTC 
Created attachment 120792 [details]
Example produced with LO 5.1

How to produce an example document: Start with an Impress or Draw document. Insert an image. Switch to text edit mode (press F2) and enter some text. Open Format > Text and set the 'text anchor' to center/bottom and the 'Spacing to Borders' part 'Bottom' to -2cm. Save the document.

The entered text will be below the image, so it can be used as description of the image. This allows to attach text to a drawing object without grouping.

Unpack the document and open the file content.xml. You will find an element style:style with style:family="graphic" and child <style:graphic-properties>. Therein you will find the attributes "draw:textarea-vertical-align="bottom" and "fo:padding="-2cm".

Now look into the specification part 1, section "20.211 fo:padding-bottom". It specifies, "The fo:padding-bottom attribute has the data type nonNegativeLength 18.3.20."

And you find the same restriction, when you follow the link to [XSL]. There you can read, "Unlike margin properties, values for padding properties cannot be negative."

OpenOffice.org has written negative values since the beginning, although in ODF 1.1 it is already of attribute type "nonNegativeLength".
Comment 1 Aron Budea 2016-08-02 03:09:53 UTC 
Reproduced in LO 5.2.0.4.
Comment 2 QA Administrators 2017-09-01 11:20:33 UTC Comment hidden (obsolete)
Comment 3 Regina Henschel 2017-09-01 16:12:12 UTC 
The problem is still unsolved in Version: 6.0.0.0.alpha0+
Build ID: 4c99b8a9de59f3c5280ff2944d9f828822897f4a
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: de-DE (de_DE); Calc: group

A valid solution is to use a fo:clip attribute with a negative offset. That would result in a different bounding box, but is as good workaround.
Comment 4 QA Administrators 2018-09-02 02:50:04 UTC Comment hidden (obsolete)
Comment 5 Regina Henschel 2018-09-02 10:42:44 UTC 
The error still exists in Version: 6.2.0.0.alpha0+ (x64)
Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04
Locale: de-DE (en_US); Calc: CL
Comment 6 QA Administrators 2019-09-03 16:11:06 UTC Comment hidden (obsolete)
Comment 7 Michael Stahl (allotropia) 2020-08-18 12:08:45 UTC 
bug still present in LO 7.0
Comment 8 Svante Schubert 2020-08-18 13:31:58 UTC 
We might want to consider to fix this in the export filter of ODF 1.2 and ODF 1.3, still not remove it but extend the standard of ODF 1.4 to allow negative padding.

By this we would become more interoperable with CSS, which does allow negative values (length) in width, margin,  padding, font-size, border-width und text-shadow.

I have not looked up OOXML, but it would be interesting to take their behavior into account as well.
Comment 9 Regina Henschel 2020-08-18 14:48:20 UTC 
(In reply to Svante Schubert from comment #8)
 
> By this we would become more interoperable with CSS, which does allow
> negative values (length) in width, margin,  padding, font-size, border-width
> und text-shadow.

Negative padding is not allowed in CSS 2.1.
"Unlike margin properties, values for padding values cannot be negative."
in section 8.4 in https://www.w3.org/TR/CSS21/box.html

Negative padding is not allowed in upcoming CSS 3.
"Negative values for padding properties are invalid."
in section 4.1 in https://drafts.csswg.org/css-box-3
Comment 10 Svante Schubert 2020-08-18 14:57:10 UTC 
Oh, thank you Regina. I was instantely clicking on the <length> link and have not read the paragraph(s) after the list:
https://www.w3.org/TR/CSS22/box.html#value-def-padding-width
Comment 11 Regina Henschel 2020-08-18 17:36:35 UTC 
(In reply to Svante Schubert from comment #8)
> I have not looked up OOXML, but it would be interesting to take their
> behavior into account as well.

The corresponding property in OOXML is the attribute "space" of borders. You find it in "17.3.4 Border Properties". Its value is specified as ST_PointMeasure simple type, 17.18.68. And there you find "This simple type's contents are a restriction of the ST_UnsignedDecimalNumber datatype".
And Microsoft restricts is further in its 'Office Implementation Information for ISO/IEC 29500 Standards Support':
"Word restricts the contents of this simple type to be at least 0 and at most 31."

So OOXML does not use negative values for padding.
Comment 12 Regina Henschel 2021-12-09 16:09:17 UTC 
I suggest to restrict the UI, so that input of negative padding is no longer possible. @Heiko, wouldn't that be something for you?

A different problem is, how to handle documents, which have already a negative padding. Any idea? We cannot silently set a negative padding to zero when resaving the document, because that will unexpectedly change the layout.
Comment 13 Heiko Tietze 2021-12-10 09:19:55 UTC 
(In reply to Regina Henschel from comment #12)
> I suggest to restrict the UI, so that input of negative padding is no longer
> possible.

Setting the minimum value on the GtkAdjustments in cui/uiconfig/ui/textattrtabpage.ui instantiated in cui/source/tabpages/textattr.cxx does this.

Loading your document still shows the text with -2cm but I cannot change it, meaning the dialog shows 0cm and either okaying this or some other positive value keeps the distance. With some visual glitches I expect the app to crash. 

Running the test in a new document seems to work flawless.
Comment 14 QA Administrators 2023-12-11 03:14:44 UTC Comment hidden (obsolete)
Comment 15 Regina Henschel 2023-12-11 12:08:19 UTC 
The error still exists in Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 43967453e15e1d054972a7586cfef8f8e0866270
CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded