<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1"> <TITLE>Cairo in an embedded environment: removing fontconfig, 16-bit RGB,porting issues</TITLE> </HEAD> <BODY>  I'm investigating using Cairo to provide rich 2D vector graphics capabilities for our embedded OS for small devices.  It does what we need and so far seems to be fantastically easy to use. However, we have to modify it in several ways to get it to work in our environment.  Presumably some of these changes aren't of interest to the general community, but others may be potentially useful patches to roll back into the distro. So I have a lot of questions related to this, and was wondering what people thought: 1. We already use FreeType, but we don't use fontconfig, and we don't    have the kind of complex file-based font system for which it would    be appropriate; nor do we want the extra code footprint associated    with fontconfig.  Therefore, we're going to have to strip down the    FreeType font backend to take out those dependencies.    Ned Konz of Squeak seems to have discussed something similar on the    mailing list a couple of years ago.  I'm at a very early stage    messing with this, but my initial feelings about this are similar    to his: we already have our own mechanisms for font selection, so    we probably don't need fontconfig's.  The only place where the    Cairo backend actually seems to *use* fontconfig's functionality is    under the toy text API, which is not necessarily of use to us.    Might it be a good idea to try to disentangle the fontconfig-based    font selection/presentation stuff from the rest of the FreeType    backend?  Are there known pitfalls associated with this approach? 2. We're using cairo-image-surface.c for a surface backend.  While we    use several image formats internally, the native screen pixel    format on our platform tends to be 16-bit r5g6r5.    Since pixman supports it, exposing it in Cairo is easy.  I'm    guessing that other people working in an embedded space may be    interested in this, since it is a common color format on small    devices.    It does bring up a naming question.  Calling the format    CAIRO_FORMAT_RGB16 would work for now, but it's far from the only    16-bit format in use out there; x1r5g5b5 is also common, for    instance, and we may well need to support it in the future.  I'm    tentatively calling our format CAIRO_FORMAT_RGB565.  Should Cairo    go to some more expansive naming convention for color formats? 3. Our OS is not POSIX-compliant, though it has some similarities.  We    also have a different build system that won't easily incorporate    the existing Cairo build process.  This means many small changes to    header includes and #defines throughout Cairo and pixman, which may    be difficult and/or undesirable to roll back into the distribution.    So I'm assuming the Cairo project proper doesn't want this stuff.    However, there are some changes that might make ports like this one    easier to do in the future (and make it easier for us to integrate    new Cairo versions), such as centralizing the POSIX header includes    under cairoint.h.  That seems to be mostly already done in Cairo    proper (not so much in pixman) but there are exceptions, such as    several Cairo source files that directly include stdlib.h.  Is    there a reason for this?  Would changes to such things be    appreciated, or are there cross-platform build issues that make it    inadvisable?    (How about pixman--is that a separate active project or is it under    the aegis of Cairo now?) Any thoughts would be appreciated... Matt McIrvin SavaJe Technologies </BODY> </HTML>