Bug 23170 - It's better to add an option to generate uncompressed content for PDF.
Summary: It's better to add an option to generate uncompressed content for PDF.
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.8.8
Hardware: All All
: medium enhancement
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-05 19:06 UTC by Lance
Modified: 2018-08-25 13:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Lance 2009-08-05 19:06:47 UTC
In cairo 1.8.8, cairo-pdf-surface.c, Line 275, I found the following code.
    surface->compress_content = TRUE;
I think it's better to add a new API to set this option so that user can get uncompressed content if they want.
Comment 1 Lance 2009-09-21 02:27:20 UTC
(In reply to comment #0)
> In cairo 1.8.8, cairo-pdf-surface.c, Line 275, I found the following code.
>     surface->compress_content = TRUE;
> I think it's better to add a new API to set this option so that user can get
> uncompressed content if they want.

In cairo-pdf-surface.c, I found more hard coded code for "compressed" parameter, such as Line 1386, 1496, 1504, 1755, 3012, 3181, 3336. I suggest replacing these hard coded "TRUE" or "FALSE" by an internal variable. Then we can add one public API to set this internal variable. The new API may looks like follows.
cairo_public void 
cairo_surface_set_PDF_compressed (cairo_surface_t *surface, bool compressed);

Since our application needs uncompressed PDF output, it would be appreciated if the API above can be added to later versions of cairo.

Thanks,
Lance
Comment 2 Adrian Johnson 2009-09-21 04:37:59 UTC
> (In reply to comment #0)
> In cairo-pdf-surface.c, I found more hard coded code for "compressed"
> parameter, such as Line 1386, 1496, 1504, 1755, 3012, 3181, 3336. I suggest
> replacing these hard coded "TRUE" or "FALSE" by an internal variable.

The "hard coded" booleans are for binary data such as images and fonts. I only made the compress_content variable control the compression of the human readable parts (ie the content stream) for debugging purposes. I was not aware of any PDF consumers that can not handle any compression.

> Then we
> can add one public API to set this internal variable. The new API may looks
> like follows.
> cairo_public void 
> cairo_surface_set_PDF_compressed (cairo_surface_t *surface, bool compressed);

There is a lot of resistance to adding APIs for controlling the non graphics related capabilities of backends. See for example this thread:

  http://lists.freedesktop.org/archives/cairo/2006-September/007956.html

The current proposals/ideas for solving this are:

- Provide a CAIRO_DEBUG environment variable that can be used for controlling debugging options such as compression, fallback images and printing backtraces.

    http://lists.freedesktop.org/archives/cairo/2008-April/013797.html
    http://lists.freedesktop.org/archives/cairo/2008-May/014059.html

  I'm not sure what the current status of this is.

- Providing a generic PDF API for inserting objects and/or obtaining only the content stream. An external library will use this API to provide control over all the non graphics related parts of the PDF specification such as hyperlinks, encryption, compression etc.

  This is something I'm slowly working on.

> Since our application needs uncompressed PDF output, it would be appreciated if
> the API above can be added to later versions of cairo.

Another option is to use pdftk to uncompress the PDF.
Comment 3 Lance 2009-09-21 17:46:53 UTC
(In reply to comment #2)
> > (In reply to comment #0)
> > In cairo-pdf-surface.c, I found more hard coded code for "compressed"
> > parameter, such as Line 1386, 1496, 1504, 1755, 3012, 3181, 3336. I suggest
> > replacing these hard coded "TRUE" or "FALSE" by an internal variable.
> The "hard coded" booleans are for binary data such as images and fonts. I only
> made the compress_content variable control the compression of the human
> readable parts (ie the content stream) for debugging purposes. I was not aware
> of any PDF consumers that can not handle any compression.
> > Then we
> > can add one public API to set this internal variable. The new API may looks
> > like follows.
> > cairo_public void 
> > cairo_surface_set_PDF_compressed (cairo_surface_t *surface, bool compressed);
> There is a lot of resistance to adding APIs for controlling the non graphics
> related capabilities of backends. See for example this thread:
>   http://lists.freedesktop.org/archives/cairo/2006-September/007956.html
> The current proposals/ideas for solving this are:
> - Provide a CAIRO_DEBUG environment variable that can be used for controlling
> debugging options such as compression, fallback images and printing backtraces.
>     http://lists.freedesktop.org/archives/cairo/2008-April/013797.html
>     http://lists.freedesktop.org/archives/cairo/2008-May/014059.html
>   I'm not sure what the current status of this is.
> - Providing a generic PDF API for inserting objects and/or obtaining only the
> content stream. An external library will use this API to provide control over
> all the non graphics related parts of the PDF specification such as hyperlinks,
> encryption, compression etc.
>   This is something I'm slowly working on.
> > Since our application needs uncompressed PDF output, it would be appreciated if
> > the API above can be added to later versions of cairo.
> Another option is to use pdftk to uncompress the PDF.

Thank you for your comments. Actually, our application needs to combine multiple pages of cairo PDF output into one PDF document. And also add some new content into this PDF document. We know that we can uncompress cairo PDF output in our application. But that will not give the best possible performance. So it would be nice if there's some way to get completely uncompressed cairo PDF output directly.

Thanks,
Lance
Comment 4 GitLab Migration User 2018-08-25 13:43:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/159.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.