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/AFPOutput The comment on the change is: Some notes on AFP New page: ##language:en #pragma section-numbers off = Notes on AFP output = Please make sure you've read the tips on ["AFPResources"]. == Interoperability == As noted in ["AFPResources"], great care has to be taken so files generated by FOP are printable on a wide range of output platforms. Problematic features include: * IOCA function sets other than FS10 * Include Object (IOB) (use page segments instead!) * Begin/End Image Object (BIM/EIM): native image formats are only supported on newer platforms (see "native" configuration setting in AFP renderer configuration) * Interchange Sets: it's important to stay at a low level. Respect maximum field sizes. == GOCA support == GOCA's vector graphic support is better than for example HP/GL2 than can be used for PCL output but it is still quite restricted compared to the capabilities of PDF or PostScript. So, simple vector images can easily be generated using GOCA but for more complex images, the image will have to be rasterized to achieve decent quality. The fox:conversion-mode="bitmap" extension attribute can be used for this. Here's an incomplete list of restrictions which can cause suboptimal representation of vector graphics: * arbitrary transformations (like skewing) * line caps are undefined (one viewer painted rounded caps while another uses butt caps) * no miter limits or line join settings * dash styles are restricted * limited clipping support (only the outer image edges, NYI) * general accuracy problems due to reduced resolution with certain painting commands. * line widths are ambigously defined in the spec and need to be assumed device-specific. In the extreme case, we may even need to make the "normal line width" configurable so FOP can adjust the calculation accordingly. * accuracy problems when using bitmap fonts because you can't scale the font by fractional point sizes. * ...and probably more == Random Notes == * We should include resource (especially fonts) at the beginning of the print file. That makes sure the resources are available to the viewers and reduces the complex setup of fonts. Furthermore, it guarantees that the printer always has the most current font files. * Instead of just referencing Charset and Codepage we should generate "Coded Fonts" (FOCA BCF/ECF) in the file-level resource group. It appears to be best practice. * There are established naming conventions for various kinds of objects. At some point we should use those. (TODO need to provide a list of those) * Add support for TLEs on page-sequence level * PTX should always begin with a PTO triplet * ev. generate Composed Text Control (obsolete but recommended) * at some point we'll need to support form maps * integrate higher-quality conversion to bi-level images that was created for PCL (!MonochromeBitmapConverter). Add setting to favor quality or speed. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
