Goals / Requirements for Fitz

[Raph Levien]

On Mon, Jul 08, 2002 at 12:13:16AM -0700, Raph Levien wrote:
> > 	http://www.haskell.org/fitz/arch/arch.html

My scribbled-upon version is below:

Goals / Requirements

    One of the most important requirements is:
    * Render the complete PDF 1.4 imaging model, with the (temporary)
    exception of In-RIP Trapping.

    It will be worth enumerating this imaging model.

    * Provide a standard API that enables applications to describe high quality, resolution-independent vector-based images for either printed or on-screen display.
    * The implementation must allow multiple back-end renderers, and must allow an application to use multiple renderers from within a single application. Some obvious examples of back ends are:
          o Pixmap-Direct - renders directly onto an RGB or RGBA pixmap
          o PostScript and PDF file writers
          o XRender
          o GDI+
          o Quartz
          o Java2D
      It is expected that some of the latter renderer back-ends will be relatively simple adapters that provide access to the appropriate proprietary 2D rendering engine via the portable Fitz API.

    I don't really expect this. Conveying pixmaps to the drawing surface
    should be relatively simple, but in almost all other cases you've
    got an impedance mismatch between the Fitz imaging model and that
    of the target engine. In many cases, the highest performing option
    is to preserve high-level operations when possible, but fall back to
    raster rendering when not.

    * Seamless support for images as well as vector-based scenes.
    Subsumed by PDF 1.4 imaging model.

    * Efficient support for animation, by enabling the application to (conceptually) specify updates to a scene representation.

    * Support for both thread-based and event-based concurreny / asynchrony in the application. Typically this will mean that window repaint / damage management will happen in a logically separate thread from construction / mutation of the image to display.
    Two separate aspects, I think. First, it should integrate smoothly
    with event-based systems such as Gtk+. I think the simplest way to
    do this is to limit the amount of time spent in any one call.

    Second, in systems where threads are available, rendering can be
    done in one or more threads.

    * Support for high-quality, scalable outline fonts, possibly employing sub-pixel positioning, hinting, and/or anti-aliasing, as appropriate.
    (basically subsumed by PDF 1.4 imaging model)

    * Attribute-based font selection mechanisms that enable applications to be written that are guaranteed to be portable to any back-end renderer implementation.
    Hmm. This one is complicated. It's certainly useful to applications,
    but is massively platform-specific. Perhaps there should be a
    platform-independent "Fitz core", plus other stuff.

    To render PDF well, you want to be able to substitute fonts
    intelligently. Here, the big challenges are encoding differences
    and width-munging (having good, free multiple master fonts would
    help a lot on the latter point).

    * (Somewhat converse to the previous point): Enable an application to precisely specify particular fonts, with the caveat that specific fonts may not be available on all platforms or renderers.
    If the application "embeds" the font, then it should _always_ be
    available for rendering.

    * Image composition with transparency / alpha-blending.
    Subsumed by PDF 1.4 imaging model.   

    * Precise Bounds Calculations: The implementation must be able to provide the application with a precise bounding rectangle for any scene or part of a scene.
    Yep. This is a special case of another goal, I think:
    * Conservative Region of Interest calculations: When objects change or otherwise need to be redrawn, the implementation must provide the application with a region containing at least all changed pixels. Libart's microtile arrays are a good basis for this functionality.

    * Constructive Area Geometry: The implementation must provide mechanisms for construction of closed shapes from sequences of straight or curved segments, and allow arbitrary composition of shapes via set-theoretic operations.
    * Flattening / Iteration: The implementation must provide the application with a means for obtaining complete information about the outline of any constructed shape, either in flattened (i.e. consisting only of line segments) or unflattened (i.e. using a combination of straight and curved segments) form.
    CAG in Bezier space is an interesting problem, not currently solved
    by Libart, and also not really needed for rendering. I think it
    should be in the wishlist, but not necessarily at the highest priority.

    * Intersection Tests: The implementation must efficiently provide tests to determine whether a shape intersects another shape, a rectangle, or a point.

    * Non-rectangular clipping: It must be possible to use any shape to clip another shape or image.
    Subsumed by PDF 1.4 imaging model.

    I'll add some more:

    * Support for both immediate mode and display list drawing. Immediate
    mode offers more low-level control, but display lists offer more
    opportunities for optimization.

    * Tuning for a broad range of output categories, including:

    + Monochrome laser printers: 1 bit, no antialiasing, hinted font
      rendering, ordered dithering.

    + RGB displays: 8 bits per sample, aa by default, unhinted font
      rendering by default).

    + Inkjet printers: around 2 bits per sample (post-dither, at least
      8 pre-dither), complex color management (6 inks or more common),
      error diffusion dithering. The value of aa is probably
      res-dependent (at 360 dpi, it might be very nice, but at 720
      dpi, not visible).

    + Imagesetters: 1 bit per sample, no aa, ordered dithering with
      precise angles. Again, font hinting is probably irrelevant because
      of the high resolution.

    It's also occurring to me that many of the goals are quantitative,
    addressing performance and quality, while others are qualitative
    (features provided). I think it might make sense to separate these.
    Here are some quantitative goals:

    * Fast rendering speed. Defining this precisely requires nailing
    down the types of images that will be rendered, the target platform
    (particularly, acceleration), and more.

    * Minimal memory consumption. This will be especially important
    when embedding into printers and other limited-resource targets.

    * Topnotch rendering quality, including:

    + Subpixel positioning of text, especially when aa and unhinted.

    + All color transforms within tight error bounds.

    + High quality image interpolation (lower quality, but quicker,
      modes can also be provided).

    + 16 bit deep output as an option.

    + Gradients rendered without bands or other visible artifacts.

    + Correct "stroke adjustment" in non-aa modes.

    + "Exact" antialiasing as an option. This removes the seam when
      alpha-compositing two abutting objects.

    + High quality dithering - Even Better Screening for inkjets,
      Well Tempered Screening for 1 bit devices, and probably a 16 bit
      to 8bit reducer (similar to GdkRgb's) capable of rendering
      absolutely step-free gradients.