How do I make FastReport generate a PDF that's viewable on iOS?

Question

I am using FastReports, and its resulting PDFs cannot be read correctly on iOS. Because iOS reads PDF/A, which FastReports doesn't support. This is apparently a known bug in FastReports 4.0, and it will be fixed in FastReports 5.0. However, 5.0 is a long way away, and has been in development for years by now.

So my simple solution - and I'd prefer a simple as possible solution, so I can remove it again once FastReports 5.0 is out - right now is to simply print the existing PDF to another PDF. Can this be done without installing a PDF printer on the system and just use Delphi?

And if not, is there a converter that accepts PDF files and outputs PDF files?

Solution 1

Try using SynPDF. It's open source, and its results are good, while managing file size to a very acceptable level. It produces PDF/A docs.

A Fast Report export unit can be found in the following location:

http://synopse.info/forum/viewtopic.php?id=781

Solution 2

I figured out my problem. To solution was to enable embedded fonts in the PDF, as I am using Tahoma and Arial, two fonts which are not available on iOS. I assume I had initially disabled this feature, to save filesize.

But I realise that I am comfortable sending a large file, even to iOS devices. So embedding fonts is the solution for me.

But I would like to give a mention to another answer by yms, which suggests using Helvetica (seeing as Tahoma and Arial are sans serif typefaces) as this is available on most platforms, including iOS. Or - perhaps as I gather from descriptions - part of the PDF engine rather than what lies on the platform.

However, despite this, I still think that to ensure that PDF is truly portable (P in PDF), one should embed all fonts, regardless of their availability. Because - who knows? - you might have some user with a PDF reader that doesn't. Oh and, it only counts for 'simple fonts', not CID fonts. CID fonts must be embedded.

In fact; as far as I understand Arial is an alias for Helvetica in the PDF spec, so it would load Helvetica instead; but it didn't work because it was a CID font.

Solution 3

Delphi, and most high level languages, allow for running subprocesses. You can use that to spawn and control ghostscript. I've successfully used this to read and convert pdfs from various proprietary, and broken, formats into properly constructed, smaller pdfs. There are quite a few options, so you will need to play around with it to get your settings correct.

Solution 4

Creating of PDF is technically editing of a new empty PDFl. The simpliest solution would be to "view PDFs" - render them to TBitmap - then copy it onto the new PDF's TCanvas. But that would kill all vector info... So probably the dummy load -> pretend editing -> save to new file would be able to do it

https://stackoverflow.com/search?q=%5Bdelphi%5D+PDF+edit - a lotta lot of PDF libraries discussed for Delphi, you can download them and try one after another, checking how different libraries fit to the kind and feature-reachness of documents you work with.

I did not marked this question a duplicate only because don't know which one would be best match here.

• How can I convert a Html file to a pdf file in Delphi
• Delphi PDF generation
• Programmtically Print to PDF
• How can I edit fields in pdf dynamically from Delphi code?
• Edit PDF documents in Delphi
• https://stackoverflow.com/questions/2539260/

View more solutions

Comments

[Svip]

I think GhostScript might be along the lines of what I am looking for. I suppose I'd preferred it had been some sort of unit/class in Delphi, but I suppose I can live with that.

[Spencer Rathbun]

@svip, I've found that most pdf libraries only provide basic features, or cost money. GS has been around forever, and will be the tool most able to read your input.

[Svip]

It was; it just wasn't able to find my fonts (Tahoma and Arial), so that's sort of weird.

[Spencer Rathbun]

@Svip yeah, telling it to find fonts is a bit of a pain. I've got the command line option needed buried somewhere, and I actually had to debug it with the Artifex people a year ago. There was a bug where it wasn't working correctly or something, but it got fixed in a recent version.

[Svip]

The thing is; when I do not provide -sFONTPATH=, it complains as it runs through the file, but it produces a file (albeit with some textual errors; ø becomes ³, for instance). When I run it with -sFONTPATH="C:\windows\fonts\" there are no complaints, but it produces a single blank page.

[Spencer Rathbun]

@Svip I don't remember what I did to get around those issues exactly, and I don't have the code at the moment. I'm pretty sure it's a font mapping issue,docs here, and you can also ask on the IRC channel. They are a great bunch of guys, just make sure you've read the docs first. :)

[Arnaud Bouchez]

+1 This is the IMHO best solution (at least using Open Source library, without the need of an external printer or conversion tool). You do not need to convert the PDF, but generate it using either PDF/A docs, either embed the fonts.

[Arnaud Bouchez]

You can embed true-type fonts subset directly from FastReport, using a third-party PDF exporter, e.g. our Open Source SynPdf, as stated by this answer. No external printer, no PDF to convert. Direct output of a file content, as recognized by mobile devices.

[Svip]

Even though I answered this question myself, I will take this as the accepted answer, because it is the best solution. It is the most forward solution, and probably be the one I eventually implement, when other issues with my program aren't as pressing. :)

[crazy_in_love]

Good to know! It's not difficult at all - you just make sure that, once you get the zip package with the needed files, go to the Synopse repository and download the latest version.

[Svip]

SynPDF seems to work fine. Only trouble seemed to be it collided with our system that uses RTTI, but we figured out to disable several features in SynPDF that wasn't interesting to us, which made it work.