Re: [poppler] [PATCH] Add -jpegopt optimize option support to utils

2018-06-13 Thread Martin (gzlist)
On 13/06/2018, Albert Astals Cid  wrote:
> You probably need to update the manpages of both utils to include that?

Done, see amended patch attached. Also updated the wording of the
other options a little, with reference to the jpeg-turbo documentation
on the options.

I note the copyright on AUTHOR below seems a little outdated, but left
that alone.

Martin
diff --git a/goo/JpegWriter.cc b/goo/JpegWriter.cc
index 37c15c2a..9ac9b63b 100644
--- a/goo/JpegWriter.cc
+++ b/goo/JpegWriter.cc
@@ -25,6 +25,7 @@ extern "C" {
 
 struct JpegWriterPrivate {
   bool progressive;
+  bool optimize;
   int quality;
   JpegWriter::Format format;
   struct jpeg_compress_struct cinfo;
@@ -46,6 +47,7 @@ JpegWriter::JpegWriter(int q, bool p, Format formatA)
 {
   priv = new JpegWriterPrivate;
   priv->progressive = p;
+  priv->optimize = false;
   priv->quality = q;
   priv->format = formatA;
 }
@@ -54,6 +56,7 @@ JpegWriter::JpegWriter(Format formatA)
 {
   priv = new JpegWriterPrivate;
   priv->progressive = false;
+  priv->optimize = false;
   priv->quality = -1;
   priv->format = formatA;
 }
@@ -75,6 +78,11 @@ void JpegWriter::setProgressive(bool progressive)
   priv->progressive = progressive;
 }
 
+void JpegWriter::setOptimize(bool optimize)
+{
+  priv->optimize = optimize;
+}
+
 bool JpegWriter::init(FILE *f, int width, int height, int hDPI, int vDPI)
 {
   // Setup error handler
@@ -137,6 +145,9 @@ bool JpegWriter::init(FILE *f, int width, int height, int hDPI, int vDPI)
 jpeg_simple_progression(>cinfo);
   }
 
+  // Set whether to compute optimal Huffman coding tables
+  priv->cinfo.optimize_coding = priv->optimize;
+
   // Get ready for data
   jpeg_start_compress(>cinfo, TRUE);
 
diff --git a/goo/JpegWriter.h b/goo/JpegWriter.h
index 9a68bcc9..bb87b949 100644
--- a/goo/JpegWriter.h
+++ b/goo/JpegWriter.h
@@ -41,6 +41,7 @@ public:
 
   void setQuality(int quality);
   void setProgressive(bool progressive);
+  void setOptimize(bool optimize);
   bool init(FILE *f, int width, int height, int hDPI, int vDPI) override;
 
   bool writePointers(unsigned char **rowPointers, int rowCount) override;
diff --git a/splash/SplashBitmap.cc b/splash/SplashBitmap.cc
index 2bec9f93..6f5e4cf8 100644
--- a/splash/SplashBitmap.cc
+++ b/splash/SplashBitmap.cc
@@ -356,6 +356,7 @@ void SplashBitmap::setJpegParams(ImgWriter *writer, WriteImgParams* params)
 #ifdef ENABLE_LIBJPEG
   if (params) {
 static_cast(writer)->setProgressive(params->jpegProgressive);
+static_cast(writer)->setOptimize(params->jpegOptimize);
 if (params->jpegQuality >= 0)
   static_cast(writer)->setQuality(params->jpegQuality);
   }
diff --git a/splash/SplashBitmap.h b/splash/SplashBitmap.h
index 092bd4cf..9756164f 100644
--- a/splash/SplashBitmap.h
+++ b/splash/SplashBitmap.h
@@ -81,6 +81,7 @@ public:
 int jpegQuality = -1;
 GBool jpegProgressive = gFalse;
 GooString tiffCompression;
+GBool jpegOptimize = gFalse;
   };
 
   SplashError writeImgFile(SplashImageFileFormat format, char *fileName, int hDPI, int vDPI, WriteImgParams* params = nullptr);
diff --git a/utils/pdftocairo.1 b/utils/pdftocairo.1
index 3a60b73e..4c32f920 100644
--- a/utils/pdftocairo.1
+++ b/utils/pdftocairo.1
@@ -305,11 +305,18 @@ When JPEG output is specified, the \-jpegopt option can be used to control the J
 It takes a string of the form "=[,=]". Currently the available options are:
 .TP
 .BI quality
-Selects the JPEG quality value. The value must be an integer between 0 and 100.
+Select the JPEG quality. The value must be an integer between 0 and 100.
 .TP
 .BI progressive
-Select progressive JPEG output. The possible values are "y", "n",
-indicating progressive (yes) or non-progressive (no), respectively.
+Select whether to write the JPEG as multiple scans of increasing quality. The
+value must be "y" or "n", with "y" indicating a progressive image, otherwise a
+single-scan image is created.
+.TP
+.BI optimize
+Set whether to compute optimal Huffman coding tables for the JPEG output,
+which creates smaller files but requires and extra pass over the data. The
+value must be "y" or "n", with "y" performing optimization, otherwise the
+default Huffman tables are used.
 .SH WINDOWS PRINTER OPTIONS
 In Windows, you can use the \-print option to print directly to a system printer. Additionally, you can use the \-printopt 
 option to configure the printer. It takes a string of the form "=[,=]". Currently the available options are:
diff --git a/utils/pdftocairo.cc b/utils/pdftocairo.cc
index 05ceaa3b..e5e49a19 100644
--- a/utils/pdftocairo.cc
+++ b/utils/pdftocairo.cc
@@ -129,6 +129,7 @@ static GBool printHelp = gFalse;
 static GooString jpegOpt;
 static int jpegQuality = -1;
 static bool jpegProgressive = false;
+static bool jpegOptimize = false;
 
 static GooString printer;
 static GooString printOpt;
@@ -369,6 +370,14 @@ static GBool parseJpegOptions()
 	fprintf(stderr, "jpeg progressive option must be \"y\" or \"n\"\n");
 	return gFalse;
   }
+} else 

Re: [poppler] [PATCH] Add -jpegopt optimize option support to utils

2018-06-13 Thread Albert Astals Cid
You probably need to update the manpages of both utils to include that?

Cheers,
  Albert

El dissabte, 9 de juny de 2018, a les 19:36:47 CEST, Martin (gzlist) va 
escriure:
> New option 'optimize=y' for utils that take a -jpegopt param,
> pdftocairo and pdftoppm. This corresponds to the cjpeg -optimize
> flag, and slightly reduces the size of the output jpeg but uses
> additional cpu and memory.
> 
> New jpegOptimize boolean in splash/SplashBitmap WriteImgParams.
> 
> New setOptimize method on goo/JpegWriter taking a boolean.
> 
> Signed-off-by: Martin Packman 
> ---
>  goo/JpegWriter.cc  | 11 +++
>  goo/JpegWriter.h   |  1 +
>  splash/SplashBitmap.cc |  1 +
>  splash/SplashBitmap.h  |  1 +
>  utils/pdftocairo.cc| 10 ++
>  utils/pdftoppm.cc  | 10 ++
>  6 files changed, 34 insertions(+)




___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler


Re: [poppler] Color conversion while rendering for printing

2018-06-13 Thread Albert Astals Cid
El dimarts, 12 de juny de 2018, a les 9:27:19 CEST, Carlos Garcia Campos va 
escriure:
> William Bader  writes:
> > ghostscript had a similar issue with performance, and they added a
> > -dUseFastColor to bypass ICC lookups. 
> > https://www.ghostscript.com/doc/9.23/Use.htm#EPS_parameters
> We can only disable it at build type, maybe we can simply add an
> specific option to disable it at runtime, instead of making it depend on
> printing option.
> 
> > They are also working on a fork of LCMS that is faster and thread-safe.
> > https://www.ghostscript.com/doc/9.23/History9.htm#Version9.23
> Great news.
> 
> > I think that only the final application to process the file should apply
> > the color conversion. Viewers know that they are the final application.
> > When poppler renders a document, it doesn't know if the results will be
> > sent to another application, to a printer that will apply its own color
> > conversion, or to a printer that will output it directly. That might be
> > another reason to make it optional.
> I agree, that's why I thought that maybe while printing, which is
> something poppler knows, could make sense to disable it.

I'd rather not make poppler smart and just add a parameter (unless you already 
have a "printing" parameter in the glib api) :D

Cheers,
  Albert

> 
> Replying to Leonard here too (I've seen his message in the list
> archives, but for some reason I haven't received the email). When
> rendering for printing, at least in the cairo backend, we just changes a
> few things like not doing any stroke adjustment, line with adjustments,
> image downscaling, etc. In the case of image streams, instead of
> rasterizing them, we try to add the stream data directly to the
> destination surface (it could be a pdf, ps or svg), but cairo always
> uses DeviceRGB for ICCBased, so even if the printer supported ICC it
> wouldn't use it anyway. So, in the end, a specific option to disable ICC
> at runtime makes more sense than using the printing one.
> 
> > William
> > 
> > 
> > 
> > From: poppler  on behalf of Carlos
> > Garcia Campos  Sent: Monday, June 11, 2018 9:10 AM
> > To: poppler@lists.freedesktop.org
> > Subject: [poppler] Color conversion while rendering for printing
> > 
> > 
> > Hi,
> > 
> > does it make sense to do color conversions using CMS while rendering
> > document for printing? I don't know much about CMS, I'm asking because
> > libcms is very very slow in some documents. When rendering individual
> > pages like viewers do, the slowdown is not that noticeable, but when
> > printing an entire document the slowdown is very annoying. I think we
> > could use the existing printing flag we pass when creating the GfxState
> > to not use CMS.
> > 
> > Thanks,
> > --
> > Carlos Garcia Campos
> > PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get=0x523E6462
> > ___
> > poppler mailing list
> > poppler@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/poppler




___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler