Float and paginal modes Leave feedback

WordProcessing module of GroupDocs.Editor, that is responsible for converting all WordProcessing formats to EditableDocument instances and backward (from EditableDocument to some of WordProcessing format), contains two modes: float and paginal (also known as paged), where first one — float, is default. These modes are presented by two properties with the same name and type:

public boolean getEnablePagination()
public void setEnablePagination(boolean)

At first, such property is present in the WordProcessingEditOptions class and is doubled in the overload of class constructor, which obtains one boolean parameter of the same name. In this case this option is responsible for selected mode during forward (WordProcessing to EditableDocument) conversion.

Secondly, such property is present in the WordProcessingSaveOptions class and is responsible for selected mode during backward (EditableDocument to WordProcessing) conversion.

Main “rule of thumb” for the end-user is to preserve the same mode during full document roundtrip and do not change it. In other words, if input document was converted to the EditableDocument (followed by the HTML emitting from EditableDocument instance) in the float mode, then the resultant EditableDocument instance (obtained from document, edited on client-side) should be converted back to the WordProcessing format also in the float mode (same rule for paginal mode too).

Main distinguish of these two modes lies in the form of representation of the input WordProcessing document. By default all WordProcessing formats internally have no pages and page division, they are internally represented as a float smoothness and pageless structure. However, they contain page-related information like headers, footers, page watermarks, page numbering formatting info etc. And when WordProcessing document is opened in some of desktop or browser-based text processor like MS Word, OpenOffice or Google Docs, this text processor dynamically and “on the fly” splits the document onto multiple pages, which are re-calculated every time when user is performing some edits in document content. For example, when user removes the line from the beginning of the huge document, the empty space is “collapsing”, and all subsequent content is like “moving upward’ to fill the gap, where removed line was located. Same real-time calculations are valid also for situations when content is added, — new inserted content is pushing the existing content to move downward, with creating new pages if necessary.

The problem is the most of used client-side browser-based JavaScript HTML WYSIWYG editors like TinyMCE or CKEditor do not support pages, page separation and described calculations at all. They support only documents with pageless structure. That’s why GroupDocs.Editor support two modes:

• In the float mode the WordProcessing document in represented in pageless form. Content is not separated on pages, There are no any page-related entities like headers, footers, watermarks and page numbers. This mode is the most suitable for almost all widespread WYSIWYG HTML-editors and that’s why this mode is default.
• In the paginal mode the WordProcessing document in represented as a set of pages, where content is divided onto pages in the same way as MS Word does. Al page-related entities like headers, footers, watermarks and page numbers are present. This mode should be turned on manually (as it is described above) and is fitting for scenarios where end-user is able to process such content in some appropriate and suitable way, for example, in his own-made HTML editing software.