Re: Commit: AbiMagick graphics class sort-of works

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Mon Aug 19 2002 - 01:51:41 EDT

  • Next message: Martin Sevior: "Why no page Size in new Page setup?"

     --- Dom Lachowicz <doml@appligent.com> wrote:
    > Hi Bob,
    >
    > I also like this proposed approach (attach meaning
    > to the text operator), but have a further question:
    >
    > What about gathering text metrics? We'll need
    > something to accommodate the following types of
    > usage:
    >
    > long int measureStringWidth ( const string &
    > inString, const string &
    > inEncoding)
    > {
    > Magick::TypeMetric local ;
    > mOffscreen.fontTypeMetrics ( inString, inEncoding,
    > &local ) ;
    > return (long int) local.textWidth () ;
    > }

    Aha this is a good point. For reasons like this, it
    is always a good idea to do either:
    1) always keep an encoding field with string fields
       when strings can be in various encodings.
    2) always use some Unicode format for all internal
       strings so that encoding info doesn't have to be
       passed around and handled differently in multiple
       places. Converting on input and output only is a
       good idea, then in cases like this you would just
       assume whatever Unicode format you've chosen.

    Andrew Dunbar.

    > I'd also like to thank Bob for all of the help he's
    > been over these
    > last few days.
    >
    > Cheers,
    > Dom
    >
    > On Sunday, August 18, 2002, at 05:05 PM, Bob
    > Friesenhahn wrote:
    >
    > > Andrew,
    > >
    > > Leonard Rosenthol forwarded your message to me
    > regarding Magick++'s
    > > inability to specify that text is formatted as
    > UTF-8.
    > >
    > > I'd like to get this fixed right the first time
    > since I try to avoid
    > > changes to Magick++'s API. It has got to be right
    > the first time
    > > around.
    > >
    > > There are two options that I see for passing the
    > text encoding option:
    > >
    > > o Add a constructor to DrawableText that also
    > specifies the encoding:
    > >
    > > DrawableText ( const double x_, const double
    > y_,
    > > const std::string &text_,
    > > const std::string &encoding_);
    > >
    > > or
    > >
    > > o Create a new drawable object for specifying the
    > text encoding:
    > >
    > > DrawableTextEncoding ( const std::string
    > &encoding_ );
    > >
    > > which is used like
    > >
    > >
    > list.push_back(DrawableTextEncoding("UTF-8"));
    > >
    > list.push_back(DrawableText(200,300,"stuff"));
    > >
    > > I currently have both schemes implemented, but
    > expect to delete one of
    > > them. I favor attaching the encoding to the text
    > since it is possible
    > > that an application uses several encodings and
    > this fully specifies
    > > the meaning of the text. In addition, adding the
    > encoding to the text
    > > allows DrawableText to be used without a list.
    > >
    > > Comments?
    > >
    > > Bob
    > > ======================================
    > > Bob Friesenhahn
    > > bfriesen@simple.dallas.tx.us
    > > http://www.simplesystems.org/users/bfriesen
    > >
    >

    =====
    http://linguaphile.sourceforge.net/cgi-bin/translator.pl http://www.abisource.com

    __________________________________________________
    Do You Yahoo!?
    Everything you'll ever need on one web page
    from News and Sport to Email and Music Charts
    http://uk.my.yahoo.com



    This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 01:54:50 EDT