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 the first one — float, is default. These modes are presented by two properties with the same name and type:
enable_pagination# bool
At first, such property is present in the WordProcessingEditOptions class. In this case this option is responsible for the selected mode during the forward (WordProcessing to EditableDocument) conversion.
Secondly, such property is present in the WordProcessingSaveOptions class and is responsible for the selected mode during the backward (EditableDocument to WordProcessing) conversion.
The main “rule of thumb” for the end-user is to preserve the same mode during full document roundtrip and not to 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 a document, edited on client-side) should be converted back to the WordProcessing format also in the float mode (same rule for paginal mode too).
The main distinction 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 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 the document content. For example, when user removes a line from the beginning of a huge document, the empty space is “collapsing”, and all subsequent content is like “moving upward” to fill the gap, where the removed line was located. Same real-time calculations are valid also for situations when content is added, — newly inserted content is pushing the existing content to move downward, with creating new pages if necessary.
The problem is that most of the 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 supports two modes:
In the float mode the WordProcessing document is represented in pageless form. Content is not separated onto pages. There are no 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 is represented as a set of pages, where content is divided onto pages in the same way as MS Word does. All 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.
Complete example
The example below loads the sample document and edits it in the paginal mode by setting enable_pagination to True. To switch to the default float mode, set this property to False (or simply leave the default).
importosfromgroupdocs.editorimportEditor,Licensefromgroupdocs.editor.optionsimportWordProcessingEditOptionsdefedit_in_paginal_mode():# Optionally set a licenselicense_path=os.path.abspath("./GroupDocs.Editor.lic")ifos.path.exists(license_path):License().set_license(license_path)# Enable the paginal (paged) edit mode; set False for the default float modeedit_options=WordProcessingEditOptions()edit_options.enable_pagination=TruewithEditor("./sample-document.docx")aseditor:editable=editor.edit(edit_options)html=editable.get_content()print("Edited in paginal mode, HTML markup length:",len(html))editable.dispose()if__name__=="__main__":edit_in_paginal_mode()
sample-document.docx is the sample file used in this example. Click here to download it.
Along with the family of WordProcessing formats, GroupDocs.Editor supports PDF as one of the output (resultant) formats. In other words, an input WordProcessing document may be opened, edited, but saved not only to the WordProcessing, but also to the PDF. The PdfSaveOptions class contains the same enable_pagination boolean flag, which, like the same in WordProcessing, has a False default value, meaning float mode, while a True value means paginal mode. If input WordProcessing document was converted to EditableDocument in paginal mode, the output PDF should be generated in paginal mode too, with enabled enable_pagination flag.
Was this page helpful?
Any additional feedback you'd like to share with us?
Please tell us how we can improve this page.
Thank you for your feedback!
We value your opinion. Your feedback will help us improve our documentation.