Bug 43692 - FORMATTING text:use-soft-page-breaks not honoured
Summary: FORMATTING text:use-soft-page-breaks not honoured
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: Other Linux (All)
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-10 06:30 UTC by josefk
Modified: 2013-11-22 09:54 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description josefk 2011-12-10 06:30:55 UTC
The value of the text:use-soft-page-breaks attribute of the office:text tag is ignored (in FODT files, at any rate).

Even if it was set to "false" before loading the document in Writer, it is always reset to "true" and text:soft-page-break tags are, as a result, scattered throughout the document.

The effect is easily reproduceable by saving a document as FODT, manually changing the value of the text:use-soft-page-breaks attribute, reloading the document and saving it again. The attribute's value will now be "true".

Its value also isn't configurable from Writer, at least not anyway that I was able to find. Does that warant another ticket? Probably.
Comment 1 sasha.libreoffice 2012-02-14 00:23:28 UTC
Please, explain what this functionality does and where (in which program) it works properly for see how it should works.
Comment 2 bfoman (inactive) 2012-07-06 06:01:27 UTC
Could you attach any example documents to allow others to check on different
system/build?
Comment 3 bfoman (inactive) 2012-10-11 18:53:46 UTC
Confirmed with:
LO 3.6.3.1
Build ID: f8fce0b
Windows XP Professional SP3

(In reply to comment #0)
> The effect is easily reproduceable by saving a document as FODT, manually
> changing the value of the text:use-soft-page-breaks attribute, reloading the
> document and saving it again. The attribute's value will now be "true".

Changed manually to "false", saved, reloaded in LO, saved, value is "true" again. 
Change back to cautious UNCONFIRMED as no more info is needed.
Comment 4 sasha.libreoffice 2012-12-06 09:42:42 UTC
Copy-pasting from:
Open Document Format for Office Applications (OpenDocument) v1.1:
Use Soft Page Breaks
The text:use-soft-page-breaks attribute specifies whether the document contains soft page breaks.
A soft page break is a page break that a has been included by a page oriented processor at a position where the document itself does not include a page break (e.g. by using the fo:break-before and fo:break-after formatting properties described in section 15.5.2).
Soft page breaks are specified by the <text:soft-page-break> elements described in sections 4.7 and 5.1.1:Soft Page breaks.
The use of the <text:soft-page-break> elements is always optional. An application generating the format may include the element if it has computed a paginated layout. A consuming application may handle the element while computing the layout, but it shall not depend on its existence. Soft page breaks are only supported within text documents.
A generating application that stores soft page breaks shall indicate this by setting the text:use-page-breaks attribute to true. A generating application that does not store soft page breaks shall indicate that by omitting this attribute, or by setting it to false.
An application that does not support pagination and soft page-breaks, that modifies an OpenDocument file, which includes soft page-breaks, shall at least set the text:use-page-breaks attribute to false (or remove it). It should also remove the text:soft-page-break elements from the document but is not required to do so.
An application that computes a paginated layout of a document should provide a facility to turn on export of soft page breaks for the purposes of consistent page breaks and for proper conversion to digital talking book formats (such as [DAISY]).
For <text:soft-page-break> elements that appear within table rows, the maximum number of <text:soft-page-break> elements that appear within the single table cells determines the number of page breaks that appear within the table row. The <text:soft-page-break> elements contained in each cell determine the positions where these page breaks appear within the cell content.
Similarly, <text:soft-page-break> elements that appear within text boxes and other content displayed outside the text flow, do not start a new page, but only indicate where the text-box's content breaks between two pages.
------end of citation----
Comment 5 Michael Meeks 2013-05-21 10:04:00 UTC
Miklos - this is an Advice_Needed bug that needs an expert to confirm/deny it :-) any chance you could get the state right there ? quickly (no need to fix it of course). Thanks !
Comment 6 Robinson Tryon (qubit) 2013-11-18 18:26:47 UTC
(In reply to comment #5)
> Miklos - this is an Advice_Needed bug that needs an expert to confirm/deny

Michael/Miklos - Any update here?
Comment 7 Miklos Vajna 2013-11-22 09:28:21 UTC
Hi,

(In reply to comment #0)
> The value of the text:use-soft-page-breaks attribute of the office:text tag
> is ignored (in FODT files, at any rate).

I think that's intentional, see the quoted text in comment 4, "A consuming application ... shall not depend on its existence."

That attribute is emitted by Writer to help other applications, where the soft page breaks are, but ignored on import, as our layout is good enough to know that information on its own.

> Even if it was set to "false" before loading the document in Writer, it is
> always reset to "true" and text:soft-page-break tags are, as a result,
> scattered throughout the document.

Correct. "false" means that *if* an application processes those tags in general, it should now process such tags for this document. But Writer never does so, that means setting that attribute to false won't change anything in the ODT importer.

> The effect is easily reproduceable by saving a document as FODT, manually
> changing the value of the text:use-soft-page-breaks attribute, reloading the
> document and saving it again. The attribute's value will now be "true".

As I mentioned above, this is on purpose. We don't need those tags, but we want to help other ODF processors by always writing them.

> Its value also isn't configurable from Writer, at least not anyway that I
> was able to find. Does that warant another ticket? Probably.

That's right. In theory we could add a config option for that, but:

$ git grep '<prop oor:name="' $(git ls-files officecfg |grep xcs$)|wc -l
2313

We currently have 2313 configuration option... I would rather avoid adding more, unless this attribute causes real problems -- but if it does, it's probably an implementation error in the ODF filter of some application, and than *that* should be corrected.

All in all, closing as not-a-bug.

Thanks for your understanding,

Miklos