On Mon, 31 Jul 2000, Chema Celorio wrote:
> gnome_print_rectangle
> gnome_print_rrectangle [ rounded rectangle ] maybe ??? maybe not
> gnome_print_ellipse
> gnome_print_line
> gnome_print_text (GnomePrintContext *pc, x, y, gchar *);
Well, although simple, it (like ::show()) is unportable:
- which encoding (UTF-8 I think)?
- Which language (as several languages have same unicode chars)?
- which direction (well - we probably encode direction in GnomeFont)
- How much letterspace and kerning to use?
- How much and which ligatures to use?
- How about glyph substitution
I would like remove ::show() entirely, and force people using glyphlists
and/or pango layouts (i.e. external libraries to format their text). But,
of course, there are situations where we simply want to print dumb
english...
> gnome_print_image (GnomePrintContext *pc, /* Print Context */
> const char *data, /* Actual image data */
> pixels_tall, /* height in pixels */
> pixels_wide, /* width in pixels */
> height, /* Image height */
> width, /* Image width */
> image_type,
> /* enum {Grayscale, RGB,RGBA, etc ..}
> rowstride) /* rowstride */
Hmmm... let's use:
gnome_print_positioned_pixbuf (pc, pixbuf, x, y, width, height);
We save yet another colorspace enumeration
> LAURIS : I am sure there are a couple of them that I am missing, can you
> expand the list ?
Still thinking...
> 2. Fill/EOFill & Clip/EOClip ( minor brakeage )
>
> We also talked about removing :
> gnome_print_eofill &
> gnome_print_eoclip
>
> and replacing the prototype for fill & clip with :
>
> gnome_print_clip (GnomePrintContext *pc, winding_rule);
> gnome_print_fill (GnomePrintContext *pc, winding_rule);
>
> This of course this breaks the Gnome Print API.
> as a second option we can add convenience method like :
>
> gnome_print_[someprefix]clip &
> gnome_print_[someprefix]fill &
No. Let's keep:
gnome_print_clip
gnome_print_eoclip
intact as convenience methods. I only would like to use single class
method for both (maintaining printcontexts is hard work if we have too
much class methods).
> 3. The next big thing since slice bread.... (medium breakeage)
>
> PDF seems to be the next big thing since the invention of slice bread.
> It is really nice and it has become the new PDL standard. Think of PDF
> as if Adobe rewrote postscript after years of limitations. We might be
> using PDF as the internal PDL in GnomePrint, but that is another story.
Just wondering, when PDF will become limitation itself...
DONT TRUST ADOBE!
> So ...
>
> There are very few (and minor) changes in the acutal PDL (Page
> Description Languaje) in PDF from the one that Postscrtip. In PDF
> there is a color pallete for fill and another one for stroke.
>
> I would like to use this new color model, which means that the color
> functions become :
>
> gnome_print_setrgbcolor_fill
> gnome_print_setrgbcolor_stroke
I do not see any reason in such distinguishion, aside compatibility with
PDF and some saved method calls.
If implemented, I would vote for one more:
gnome_print_setcolor_text
> Or even better :
>
> gnome_print_setcolor (GnomePrintContext *pc,
> gboolean fill (if false = stroke),
> gint colorspace,
> val1, val2, val3, val4);
>
> where colorspace is an enum of :
> GNOME_PRINT_COLOR_RGB
> GNOME_PRINT_COLOR_RGBA
> GNOME_PRINT_COLOR_CMY
> GNOME_PRINT_COLOR_CMYK
> GNOME_PRINT_COLOR_watever ...
>
> RAPH : Is this funciton prototype extensible for use in Spot Color ???
>
> 4. Documentation
>
> I have been thinking of starting to write some docs for GnomePrint,
> feel free to help me out with them.
Lauris