jpakkane / capypdf Goto Github PK

When setting the fill and stroke, we have different names for the functions used to set shape and text fill and strokes:

shape_ctx.set_nonstroke(fill)
text_ctx.nonstroke_color(fill)

These kinds of functions should be harmonised, as much as possible.

Or in other words "when and how should color conversions happen"? There are many different, and totally reasonable, ways of doing this. Such as:

• Pass all colors through without conversions
• Convert everything silently to target colorspace
• Error out if trying to specify a color that is not in the output colorspace
• Same as above but also permit ICC and Lab* colors

As an example suppose you call cmd_rg while creating a PDF/X3 CMYK output file:

• writing an rg command in the stream must not happen as it would create an invalid PDF
• converting to device cmyk is probably what the user wants and doing the conversion ourselves is convenient for users, because then they don't need to do it
• on the other hand in some programs it would be considered an error if they ever try to set an RGB color and thus would probably want an error rather than a silent conversion

There are more complicated cases to consider as well. Suppose you load an RGB image when generating a PDF/X3 file. Then you'd probably want to express the rendering intent to use for the conversion. Currently you can't.

Many of the text style commands are the same as the drawcontext commands that are already written. I'd like to be able to share the code so there's not duplication for things like RG/rg, cmd_gs etc.

Is the best way to do this to create a graphics specific base class or side class?

OR

Perhaps we could create a DrawContext during render text to process all of those commands, maybe forcing in our own cmd_appender so they happen in the right order?

OR

Make render_text append directly to the master drawcontext cmd_appender instead of building a seperate string first, so graphics operators can be inserted by calling them mid-stream.

OR

Copy pasta all the graphics code?

Add GObject Introspection support for the C API.

That way CapyPDF would be available for more languages.

The current raster API is proving to be a little difficult to work with, both because I have to load data into memory then save it to temporary files after modifying it and because the results are incorrect (reduced/wrong colors). I want to get you a more specific bug report for the color problems importing jpeg and png images, but I also want to add a raster data api which would insert the raster bytes prep-prepared, converted to the right icc profile on the python side and coded into the jpeg or pdf bitmap formats.

Would you have any objections to this API addition?

The fallback font on linux '/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf' produces the error "Index out of bounds." when it is loaded using gen.load_font(filename)

DejaVuSans.zip