OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Graphics formats


Dave Pawson <davep@dpawson.co.uk> wrote on Sun, 17 Apr 2005 17:48:20
+0100:

> Come on docbook-ers, how do *you* generate your images

Here's what I think is the common wisdom:

1. If your graphic data is in vector format:

   * Keep it in vector format for as long as possible during the
     vector pipeline. I.e., never explicitly convert it to raster
     format.

   1.1. If you are targeting print output:

        Since you'll probably be generating PDF or PS, you'll
        typically convert your graphics to (vector-format) PDF or EPS.

   1.2. If you are targeting Web output:

        The most common formats are SVG and Flash. I think the former
        should be preferred as it is an open, non-proprietary XML
        standard (and a W3C recommendation) for which many open and
        non-proprietary processing tools exist.

        Since all vector-based Web graphics formats currently require
        browser plugins (and in any case will continue to demand
        sophisticated browsers), for maximum portability you will want
        to offer an alternative raster image (inside an <object> tag,
        for example). See 2.2.2 below for the recommended format.

2. If your graphic data is in raster format:

   2.1. If you are targeting print output:

        Since you'll probably be generating PDF or PS, you'll
        typically convert your graphics to (raster-format) PDF or EPS.

   2.2. If you are targeting Web output:

        2.2.1. If your data are composed of smooth transitions
               (typically, this includes all photographs and almost
               nothing else):

               Use a lossy format enabling a high compression rate at
               almost no visible loss of quality (JPEG/JFIF).

        2.2.2. If your data contain discrete colors, drawings etc.
               (this includes most non-photographic data, or
               photographic data with line graphics overlaid):

               Use a lossless format. I highly recommend PNG as it is
               open, includes compression, and is widely supported
               (except for alpha-channel transparency by Microsoft
               products).

               For discrete-color drawings, you get better compression
               ratios than JPEG, at perfect quality, while JPEG
               creates salient approximation artifacts.

               There is almost no reason to use GIF anymore, as PNG is
               much more versatile and often more efficient.
               Exceptions are alpha-channel transparency for use with
               Microsoft products (well supported by the open-source
               community however) and animated raster graphics (MNG is
               still not very widely supported).


The essence: Don't throw away any information if you can avoid it.
Note that PDF and PS/EPS can represent both raster and vector data.

There are open-source tools for essentially all conversions that arise
in practice. The hardest are probably conversions to and from SVG. I
wrote a couple of Java classes for converting SVG <-> EPS based on
batik.  E-mail me if you're interested.

Justus

-- 
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Université de Liège, Belgium    Fax:   +32-4-366-2620



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]