Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks The comment on the change is: Update to reality ------------------------------------------------------------------------------ = General = * /!\ Answer questions on the fop-users mailing list. - * /!\ create a release plan once we can see that we can start releasing again. (in progress see ["ReleasePlanFirstPR"]) == Documentation == @@ -24, +23 @@ == Interfaces and frontends == + (nothing here ATM) - * /!\ Write a specification for the API and vote on it. (in progress) - * complete renderer plugabillity (following the pattern used by FOP extensions and XMLHandlers) - * Revisit configurability by userconfig.xml - * Split engine configuration from per-run configuration == AWT Viewer == @@ -40, +36 @@ * Check text-decoration (it was disabled after a change in property handling for text-decoration) * Improve property evaluation. No percentages, yet and "auto" values cause warnings. + * Better support for nested tables + * Problems with tables in static-content (messes up the document in Word) == Fonts == @@ -54, +52 @@ = FO Tree = * Remove FONode.getLogger() and make "log" protected instead. - * Allow empty table-cells (with strict validation turned off) * Allow region-before before region-body (with strict validation turned off) * Better handling of the difference of strict and relaxed validation * central error message producer @@ -65, +62 @@ = Layout managers = - * Resolution of over-constrained documents (see ["FOPOverConstraintDesign"]) * Detailed documentation of layout system and overconstraint resolution (see also ["FOPWorkEstimates"]) @@ -87, +83 @@ * Reimplement table-and-caption and table-caption * footnotes/before floats - * layout of footnote with other layout managers - * adding footnote area to area tree * space resolution in footnotes + * add proprietary option that doesn't span a footnote over all columns of a multi-column document + * fix the problem with footnote handling in multi-column documents * keeps * remaining issues with keep-with-previous (see keep-with-previous2-5) @@ -103, +99 @@ * graphics * tests for e-g and i-f-o (look at line-stacking-strategy and place of images in a line) - * Improve handling of file URLs (ex. file://localhost/myfile) - * custom image/stream injection + * custom image injection * Make image providers pluggable and priorities per image format, not per provider. == Inline areas == * ipd adjustment after page number resolution - * Kerning support is missing in the text LM. It is supported by the PDF renderer but the PDF renderer will currently apply kerning where it actually shouldn't (since it's not respected by the layout engine). * min/opt/max support for line-height, especially concerning space-resolution (space-before, space-after) == Adding Areas == * must be able to adjust spacing (works in many places but not on tables, for example). * add id/markers (some remaining problems when content is broken over multiple pages) - * check that all areas contain the proper traits ---- = Area Tree = * Writing mode, stacking direction and orientation, width/height vs. ipb/bpd. (See ["FOPWritingModesAndBidiDesign"]). - * Develop an intermediate format (serialized representation of the area tree, probably XML-based, not serialized objects) that people can use to do manual modifications (impositioning ("two-up"), tweaking, OMR support etc.). Strategy needs to be determined first. + * Extend the intermediate format to support imposition ("two-up" etc.) ---- = Renderers = - * The renderer interface is used by the {{{LayoutHandler}}} and {{{AreaTree}}} for setup, page sequences and pages. - * Inline areas render themselves on the Renderer. - * The abstract renderer is meant to completely handle the area tree without doing any rendering. So that renderers that subclass this only need to override those methods that require/support particular areas. - * The super methods can be used for normal area tree handling and renderer positioning. * Check that the current renderer design is suitable and covers all areas in all situations. * Especially make sure the clipping can be done in a way that is supported by all renderers - * Minimal work for subclasses to override {{{AbstractRenderer}}}. * Avoid type casting where possible. - * Is the {{{BlockViewport}}} handled appropriately? * Can different orientation and stacking directions be handled? Should document extensions have an extension handler so that user defined extension can be handled? - * Bring back all the other renderers: PCL, AWT, TXT + * Bring back all the other renderers: PCL, AWT, SVG, MIF * Develop new renderers: AFP, maybe EMF * Revisit the way absolutely positioned areas are rendered. The break-out mechanism can probably be avoid by taking the area out of the normal flow. Maybe look at z-index at the same time. @@ -157, +144 @@ * separate into a stand-alone library (remove Commons Logging dependency) * documentation * optimisations - * some additions so it can load and read pdf documents + * some additions so it can load and read pdf documents (investigate switching to PDFBox) * maybe add possibility to generate PDF 1.3 only (must be configurable) * encryption (partly done, needs fixing, add support for PDF 1.4 level encryption) * Improve building of PDF dictionaries (also needed to properly finish PDF encryption for string and text entries) @@ -166, +153 @@ === SVG support for PDF === - * Investigate the problem of badly scaled SVGs (probably caused due to a recent change for the Transcoder, removing the second "cm" in PDFXMLHandler helps but that can't be the solution) * text drawing improvements. Also see ["FOPBatikTranscoders"]. @@ -174, +160 @@ == PostScript renderer == * Support for TrueType/multibyte fonts - * Fix leaders * SVG text painter (basics are there) * Provide level 2 and 3 (make configurable) @@ -201, +186 @@ * Move MathML extension to a more visible location (what's that?) * Finish new FOP extension for Barcode4J, make a release of Barcode4J and bundle with FOP (Jeremias Märki) * Work with Cocoon to produce a new FOP Block (because the API has changed). - * Integrate support for RFC 2397 URLs directly into FOP. ([http://marc.theaimsgroup.com/?l=fop-user&m=110875657902117&w=2 Generic solution]) == SVG == @@ -210, +194 @@ == Images == * Image subsystem needs a refactoring. See ImageSupport. This includes the point right above for SVG. - * FOP extension and programmatic facility to set proxy information that FOP could use to access external resources. (Note: HTTP/FTP proxy information is usually set using system properties and can be done via the Java command line. HTTP proxies requiring authorization need to have a specific HTTP header set. The current URI Resolver scheme which allows custom resolvers to be added to FOP may actually suffice to realise this feature.) == Cleanup == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
