Possible to post your test code?
Given:
for _ <- 1 .. 1024, do: elem(:timer.tc(fn -> ChromicPDF.print_to_pdf({:url, "file://test/integration/fixtures/test.html"}) end), 0)
It is pretty good for simple case, prints in 10ms (binary returned inline as encoded. With output to file it runs a bit slower when the document is small.
Hey @silverdr
Yeah, unfortunately that is about the amount of error information ghostscript usually gives us 
It’s a blast. Not sure what is wrong exactly, could be incompatibilities with the version of Ghostscript you’re using, or some setup thing. Unfortunately that part of ChromicPDF is rather fragile, though we are using the feature ourselves - currently at Ghostscript 9.55 in an Alpine 3.15-based container. Will take a look into Ghostscript 9.56 when I find the time, created a ticket for it.
Regarding your speed & size concerns: As you said, these are out of ChromicPDF’s influence unfortunately. Still good to know, of course. If people are looking for minimum PDF file size, rendering with Chrome is likely not the way to go.
Usually it’s blazing fast for us, and magnitudes faster than anything that starts fresh Chrome instances for each PDF. Of course it is possible that wkhtmltopdf is still faster though, perhaps due to the faster rendering engine. But I have doubts and the “2 to 2.5 times slower” you quote seem a lot.Thanks for your feedback though!
malte
Not really a test code. I print_to_pdf/2 HTML strings of real-life documents and output: the PDF to file. I am not entitled to share those docs but while they are not trivial like the “Hello, world!” type of fixture you refer to, they’re not overly complex either. Less than three pages “Letter”, single font face, an image or two etc. As mentioned, this type is worth about 40 to 50 KiB for wkhtmltopdf, which renders and saves them consistently a tad under one second. With Chrome it is much more unpredictable (higher deviation) but not less than two seconds so far.
Thank you for coming back on it. I’ll see if I can get an earlier Ghostscript version on the dev machine. As for the speed, I am wondering what might be the reason if you say ChromicPDF might even be faster than wkhtmltopdf. Do I understand correctly that /unless/ I set on_demand: true option, the default setup is pooled with some default pool sizes mentioned in the docs, right? Maybe there lies something because I haven’t noticed any significant difference between the two setups. But I didn’t specify any pool options. And yes, zombies invaded my machine in this setup so I took it worked
Do I understand correctly that /unless/ I set
on_demand: trueoption, the default setup is pooled
Yes, on_demand essentially bypasses the entire supervision tree booting, and instead starts the relevant ChromicPDF processes as well as the external Chrome process when you call print_to_pdf. So, if you’re testing this for example in a .exs script and only print a single PDF, these two modes of operation will in fact appear to behave the same. You should notice a drastic difference when you perform manual tests on the console and print multiple PDFs.
In order to debug this further though, it would be great if you could provide a minimum working example, i.e. some benchmark script with a PDF template that shows the slowness/unpredictability you’re experiencing.
Do you think your project may evolve and become more versatile, because I still can’t find a elixir library easy to use to just extract the words in a pdf.
Roger. I’ll check it all step by step in a day or two and if nothing helps I’ll make a “dummy” HTML document of the type in question and provide it for checking. Tnx so far once more.
If OCR → tesseract. Write your own integration. Otherwise be careful with deceptive glyphs.
