

Ask HN: Is PDF generation a real pain for developers? - knkella

Recently we launched a PDF generation service on cloud by the name of Pagify http://pagify.io for developers. Our main assumptions were:<p>1) It is tedious to code the layout and design of the PDF using code libraries such as FPDF, Prawn etc.<p>2) When it came to generating large no of PDFs it is difficult to scale.<p>3) Developer wants to focus on the core offering of their web product rather that spending their time on stuff like PDF generation, email, image processing, payments etc.<p>4) In cloud development model off-the-shelf components are preferred in the form of cloud services or cloud API over code packages or software. So PDF generation offered as a service instead of code library is better.<p>Targeting these assumptions Pagify offers a designer within the browser where users can design their PDF template and use an API to generate PDFs.<p>But after launching on HN and betalist we received mixed feedback on Pagify. Do you think our assumptions are correct? And does Pagify solve this problem?<p>Thanks, Kush.
======
danielstudds
I work in the DOCCM (Document Output for Customer Communications Management)
space, which in a certain light is just generating PDFs (well, perhaps a bit
more complex than that...). Enterprise deals in this space will have 6 or 7
zeros, so yes, there is a market for generating PDFs. There are already some
cloud providers out there (like exari - it's been a while but I remember their
stuff being pretty cool.)

That's a bit different from vanilla PDF generation, but perhaps a good portion
of that is down to marketing. How you position this could be important. You've
got your salesforce version - nice :-) That should mean you're selling direct
to a business user, so have you worked out what their pain point is? Do they
think of it as "generating PDFs" (you've branded it as "Great Reports", so
obviously you think they don't!) I don't know anything about report generation
on SF, but I'd be shocked if there wasn't already some competition - have you
looked in to that? What's your point of difference?

Down to your assumptions: 1) I've only ever used FOP & yes it is tedious, but
it gives you a lot of power, and that power is going to be hard to replicate.

2) Generating large no of PDFs is hard to scale. For a cloud service, though,
you need to work out how you're going to deliver a large number of PDFs over
the wire. (You'll easily be able to generate more bytes of PDF per $ of CPU
than you'll be able to transfer per $ of bandwidth.)

3) That sounds like a safe assumption (almost a tautology).

4) I'm not so sold on this. If I can get equivalent functionality from a
library, I'll use the library. I don't want to add a dependency on an external
service (making my own service more fragile) unless it offers a significant
benefit. Stripe saves me SO MUCH TROUBLE it's a no brainer. There's is no way
I would even think of trying to replicate what they've got. The barriers are
significant. What are the barriers to me using a library instead of Pagify?
Not nearly as great.

Gut feeling, the SF report generation product is much more compelling, but
check out the competition in that space.

~~~
knkella
Thanks for the feedback. We are going after the SF market, but there is
already competition. As far as pricing model is concerned we would do that on
the no of pages one generates. Do you think developers are not the right
market? Can we offer it to developers in some form?

~~~
danielstudds
PDF generation is a complex business... you're not going to be all things to
all people, you need to choose a particular niche (at least to start with) and
make that work. I can see the value prop in report generation on SF. "PDF
Generation for developers" is too broad: I don't think you can do it (because
there are so many different types of of PDFs to generate) and I can't see the
value prop (because it's going to cost you more to provide a generic PDF
generation service than it will cost me to use an existing library.)

That said, there might be a market there for developers, but you'll need to
identify a very particular challenge that devs have and provide a much better
solution than what they can achieve with a library in a day.

------
dbond
It is tedious to layout a PDF but actual pain points are handling variable
sized images and amounts of text, try formatting recipes to a PDF... Your demo
video explains the features but not how it can solve anything that is a major
problem to me.

The concept here in designing a template to be filled later is a brilliant
idea, but I think its the delivery of the product that may pose the biggest
problem. PDF generation doesn't have the same level of complexity as video
encoding or payments so when it is used, its expected to just work as the
environment doesn't change.

This introduces what I think is the main issue, if I build a website for a
client, as a developer I never want to see it come back with problems, so its
not worth introducing the risk of a third party service for the sake of a few
hours of tedious work. At the other end of the industry any company producing
a webapp may have problems with this simply due to how fundamental the feature
can be, PDF generation doesn't require the same infrastructure as video
encoding or payments, so they will have very different tradeoffs. Your main
problem here is that you have no competition so I have nowhere to go if you
close and the design online feature is essentially a vendor lockin.

Your assumptions are right but they are what a developer wants, the decisions
are mostly made by management where future risk is more important than short
term convenience.

Personally I think this product in particular would be much more suited to
being a standalone package.

~~~
knkella
Thanks. Do you think by using an HTML template that can be filled in later is
a better idea than visual designer?

~~~
dbond
The visual designer is great, it adds back in the ability for the designer to
alter the template without the developer having to change any code. If this
was a standalone product the template format would most likely need to be a
proprietary format anyway for some basic piracy protection.

~~~
knkella
Thanks we will start looking for its uses as a stand alone product.

------
LarryMade2
Ive used FPDF/FPDI most of the time I used it to generate preformatted mailing
labels (the best output method that is compatible with any printer, just
format it with scaling "off" in mind.) Maybe a letter or report or two...

But the main thing that drew me to PDF utilities was to programmatically fill
out pre-existing PDF forms. With FPDI i would load in the form and then
overlay the data on top of it. Not as easy as charts and tables, as some data
exists as one line per row and other might have several lines per row of data.
different positions, etc. (here's a fun form I had worked with:
[http://www.cdss.ca.gov/cdssweb/entres/forms/English/CD9600.P...](http://www.cdss.ca.gov/cdssweb/entres/forms/English/CD9600.PDF)
depending of family size or care situation could be multiple pages...) If you
can crack stuff like that in an easy-ish to use API, I think you would catch
more developers interest.

------
subsection1h

        It is tedious to code the layout and design of the
        PDF using code libraries such as FPDF, Prawn etc.
    

I recently used Prince[1] to generate a PDF version of a web-based book. The
PDF needed to be suitable for professional printing (crop marks, bleed, trim,
etc.). Prince was the only solution I could find that came even close to being
adequate for the job, and it exceeded my expectations. Creating the HTML for
Prince wasn't tedious at all. It was almost a pleasure because Prince includes
better support for print-related CSS3 properties than any rendering engine
I've encountered. There's a web-based service named DocRaptor[2] that is
powered by Prince.

[1] <http://www.princexml.com/>

[2] <http://docraptor.com/>

~~~
ashokvarma2
PrinceXML doesn't support a lot of the Html5 and CSS3. Canvas support doesnt
exist, so I cant print charts.

~~~
usladha
I havent tried charts with princexml, but flying-saucer has capability to do
custom rendering. So if you want, you can use a service to get image of your
chart and then render that in the pdf as image.

~~~
knkella
Our service has built in charts support. Check out Pagify and let me if it is
something you will use?

------
jyu
The target market that will pay for PDF generation is probably not developers.

A competent developer can generate PDF's with the mentioned libraries rather
quickly. We deal with a lot of PDF generation where I work, and it is not
something that enters our minds to outsource because it's pretty fast and easy
to do. For us, the generated PDF's do not need great design or layout, they
just need the info in a printable format.

That said, you may find a better audience with less tech savvy users that have
a lot of reporting needs. I can't really think of a target audience off the
top of my head. Good luck to you.

~~~
ashokvarma2
I disagree, If we are dealing with simple invoices and stuff. Once you start
dealing with reports containing charts, it all goes haywire

------
ashokvarma2
Its a terribly painful. I have tried every single one of the options. I am
still finding it extremely difficult to get it working. Once I managed to get
it to print to pdf, then started the bigger problem 'Paging'.

Paging is quite painful. I am writing my own code to split tables to fit into
pages.

If you can solve this problem. I would gladly pay.

~~~
knkella
We are looking into dynamic layout where tables can be split. It would be
great to work along side you. Can I have your contact?

~~~
ashokvarma2
Oh man, if you can solve it for me, I will be eternally grateful. You can
email me at ashok (at) reportgarden (dot) com

------
palidanx
I rolled up my own solution for rails here.

[http://ror-snippets.tumblr.com/post/40142053834/converting-h...](http://ror-
snippets.tumblr.com/post/40142053834/converting-html-to-pdf)

Imo only a subset of people have pdf generation needs (mainly devs)

------
edoceo
It's super easy here, I'm generating nice multi-page PDFs with colours and
images and all that - from HTML5 based content. I have a similar API available
at <http://edoceo.io#pdf>

------
jdietrich
Not amongst the kind of people who read HN. You might get some traction with
semi-skilled PHP developers, but they rarely have much of a budget to work
with and will generally use whatever is the cheapest acceptable solution.

~~~
gee_totes
This comment is wrong. PHP is a total mess when it comes to pdf generation,
even skilled developers have to resort to things like TCPDF.

This service would provide a good alternative, and regardless of what the
developer is making, the price of the service would be far lower than paying
the dev for the amount of time they spent futzing around with PDFs in PHP.

------
gee_totes
Can I send a URL to the API and it will return a PDF? That is something I
would use for sure.

~~~
knkella
Yes it will. Can we talk more about it?

~~~
gee_totes
So I could send it www.google.com and it would return a .pdf of google.com,
exactly as it would look in the browser?

~~~
knkella
Sorry I must have misunderstood. That is what HTML2PDF engines do. We generate
PDFs using our own templates.

~~~
gee_totes
Yeah, sorry if I wasn't clear. I'm looking for a service that will do HTML2PDF
from an API call.

HTML2PDFAAS, as I like to call it :)

------
factorialboy
Browsers let you print a page as PDF. Which use-cases does Pagify solve?

~~~
knkella
It does print the web page. But when it comes to print-friendly reports and
quotes you need some library or print ready web page. So we allow developers
to create a template that is print ready. And then using an API call they can
merge data and generate PDF.

------
knkella
Help us understand PDF generation and its problems.

