Editing XSL Formatting Objects (section)

==Drawbacks==
{{Original research|section|date=June 2019}}

* '''Limited capabilities''' – XSL-FO was specifically designed to meet the requirements of "lightly designed" documents typified by technical manuals, business documents, invoices, and so on. While it can be and is used for more sophisticated designs, it is inherently limited in what it can do from a layout and typographic perspective. In particular, XSL-FO does not provide a direct way to get formatting effects that depend on knowing the page position relationship of two formatting objects. For example, there is no direct way to say "if this thing is on the same page as that thing, then do X, otherwise do Y". This is an explicit design decision reflecting the two-stage, transform-based abstract processing model used by XSL-FO. This limitation can be addressed by implementing a multi-pass process. Unfortunately, there is currently no standard for how the result of the first pass would be communicated back to the second pass. Most, if not all, implementations provide some form of processable intermediate result format that can be used for this, but any such process implemented today would, by necessity, be implementation specific.
* By the same token, there are important '''layout''' features that are simply not in XSL-FO, either because they were not of high enough priority or because designing them was too difficult to allow inclusion in version 1.1, or because there were insufficient implementations to allow their inclusion in the final specification per W3C rules.
* In addition to these architectural limitations, the current XSL-FO implementations, both commercial and open source, do not provide the same level of '''typographic sophistication''' provided by high-end layout tools like [[QuarkXPress]] or [[Adobe InDesign|InDesign]], or by programmable typesetting systems like [[LaTeX]]. For example, no current implementation provides features for ensuring that text lines on facing pages are lined up vertically. There is nothing in the XSL-FO specification that prevents it but nothing that requires it either. For most documents for which a completely automated composition solution is sufficient, that level of typographic sophistication is not needed. However, for high-end publications and mass-market books, it usually is; in some cases this can be met by using XSLT to generate a [[LaTeX]] document instead.
* '''Extension dependency''' – When considering the applicability of XSL-FO to a particular document or document design, one must consider proprietary extensions provided by the different XSL-FO implementations. These extensions add features that are not part of the core specification. For example, one product adds support for Japanese typographic conventions that the XSL-FO specification does not address. However, use of these features makes such an XSL-FO system a little more bound to a specific implementation (but not completely bound as it would be when using a totally proprietary composition system.)
* '''Impractical manual editing''' – It is generally impractical to edit XSL-FO instances by hand (XSL-FO was designed for clarity and completeness, not ease of editing.). Visual editing tools such as XFDesigner can alleviate the task, although not all XSL-FO tags are accessible (most notably markers and footnotes). XF Designer is no longer a supported product from Ecrion Software. 

When trying to decide whether or not XSL-FO will work for a given document, the following typographic and layout requirements usually indicate that XSL-FO will not work (although some of these may be satisfied by proprietary extensions):

*Need to restart footnote numbers or symbol sequence on each new page (however, some implementations provide extensions to support automatic footnote numbering.)
*Need to run text around both sides of a floated object (XSL-FO can run text around one side and the top and/or bottom, but not both sides; however, some implementations provide support for such complex layouts via proprietary extensions.)
*Need to have variable numbers of columns on a single page (however, at least two commercial implementations provide extensions for creating multi-column blocks within a page.)
*Need to have column-wide footnotes (several implementations provide column footnote extensions.)
*Need to have marginalia that are dynamically placed relative to other marginalia (for example, marginal notes that are evenly spaced vertically on the page). XSL-FO only provides features for placing marginalia so that it is vertically aligned with its anchor.
*Need to create content that spreads across two pages as a float or "out of line" object in an otherwise homogeneous sequence of repeating page masters (this can be done in XSL-FO 1.1 using multiple body regions and flow maps, but it requires being able to control the page masters used for those pages.)
*Need both bottom-floated content and footnotes on the same page.
*Need to be able to run text against an arbitrary curve (though some implementation support [[Scalable Vector Graphics|SVG]], which can be used to get around this limitation).
*Need to be able to constrain lines to specific baseline grids (for example, to achieve exact registration of lines on facing pages.)
*Anything that requires page-aware layout, such as ensuring that a figure always occurs on the page facing its anchor point.