* V7 PDF creation very slow, creating huge files

[tatewise]

Put to one side the problem of images in reports that FH saves to RTF.
MS Word can save to PDF using Family Historian PDF with every text format under the sun as PDF searchable text.
FH can save to RTF which opens in MS Word and similarly saves as PDF with all the rich text rendered as text.
So it would seem an FH choice to only send images to Family Historian PDF.

[ColeValleyGirl]

So it would seem an FH choice to only send images to Family Historian PDF.

I very much doubt it's a choice.

[NickWalker]

I don't have any inside information on this and have no knowledge as to how FH deals with the PDF conversion. But my gut feeling is that it will be a major job to get it to output in text rather than graphical form. Hope I'm wrong.

[PeterR]

FH Diagrams (and FH Help for that matter) can all be printed/saved to PDFs with searchable text. And this problem with Reports and Books is new to FH7.

[ColeValleyGirl]

It isn't only a PDF issue -- it affects xps/oxps output as well. Which points a finger at some Microsoft interface... since nobody else supports xps.

[AdrianBruce]

Hmm. It's clearly not simply a matter of saving text into a PDF - it's the need to save a correct configuration of text, images, etc, all marked up with ... whatever PDF needs. Not just my report, but everyone's... Come to that, I doubt very much that CP have written their own word processing - they must have some rich text controls / objects and they have to get the data out of that and into a PDF.

My only reason for mentioning the RTF issue with images is to illustrate that even in v6, FH was bumping up against limits.

[LornaCraig]

I think everyone is agreed that V7 is slower than V6 at creating PDFs and it creates large files. But there are some other very odd things going on.

Some people are apparently unable to get FH to produce any complete PDF versions of reports. They apparently see only headers and footers. But we don't all have that problem. Helen suggested that it might be because she has extra memory available on her PC (64Gb), but I have only 16Gb on desktop and 8Gb on laptop and I don't have any problem generating PDFs.

On the other hand, as I have mentioned in another thread, while I don't have a problem with PDF creation I am having some obscure issues with report generation. When testing on both desktop and laptop with an identical Ancestors by Generation narrative report I noticed that the report generated by FH on the desktop was 129 pages long and the report on the laptop was 121 pages. This was as viewed in FH, before saving. I have the same report options set on both. Saving as PDF then faithfully reproduced the 129 pages and the 121 pages respectively. I haven't waded trough the whole report to spot all the differences but in some places it seems to be a matter of extra spaces between lines, especially (but not only) in the Source lists.

[Mark1834]

It’s not memory - both FH and the PDF driver are 32-bit apps, so are incapable of using more than about 3.5 GB each, however much your PC is stuffed with.

Regrettably, I think Nick is right. CP have clearly been aware of this issue for some time, so it is likely that any easy fix would have been implemented by now, or at least promised for the first service release.

[tatewise]

Lorna, in the Report window, check the Printer Setup... on the right.
Is the Printer Name your local physical printer?
If so then the differences are probably due to subtle differences in their printer drivers.
What happens to the page count if both are set to Family Historian PDF?
For me, that sort of change can alter the page count.

[PeterR]

CP clearly knew how to produce Reports as text-searchable PDFs in FH5 and FH6. Why have they forgotten for FH7?

[NickWalker]

I'm only guessing with my developers hat on and I may be completely wrong. But I can imagine a scenario where CP may be using a new control for reporting in FH7 which is entirely different to the one they used in the past and different to the one used for charting. And that control may have a built in 'export to PDF' function * - see edit below) but only does that in graphical form rather than text and graphics. I could easily imagine not spotting that until very late in the day when end users start complaining. So in order to get it to export in a different way could be very difficult. Like I said I hope I'm wrong!

*Edited later: Actually having thought about it further, the converting to PDF is being done by the novaPFD utility so if my imagined scenario was correct it would be the built in 'print' routine that was generating graphics only (not export to PDF). As someone else (probably Mike) mentioned it might be possible to get it to export to RTF and then send the RTF to NovaPDF but again not a trivial thing to do.

[LornaCraig]

Lorna, in the Report window, check the Printer Setup... on the right.
Is the Printer Name your local physical printer?
If so then the differences are probably due to subtle differences in their printer drivers.

Ah, yes thanks Mike. That explains the difference. They are the same when both set to the FH PDF printer.

[AdrianBruce]

CP clearly knew how to produce Reports as text-searchable PDFs in FH5 and FH6. Why have they forgotten for FH7?

I very much doubt that they have forgotten. As I understand it, the text in v7 can be much more sophisticated in what gets printed, what with the "rich text" in notes, etc. That wasn't in v6.

Worst case scenario: the more sophisticated text isn't printing via the (presumably bought in) software that CP are using and the only way to get it into a file is to image it, rather than produce text marked up.

That's why I fear this may take some time.

[Nalaho]

I've just run into the large file problem too. Wishing to send a descendant report to relatives in Canada I generated a full narrative report including some 17 generations. A few thumbnail jpegs were included. The report was created quite quickly but I have a lot of memory on this PC (24 GB) and the processor is pretty fast. Saving as a PDF or printing through PDF "printers" all generated reports some 130 pages long but about 130 MB in size. I hadn't really noticed the size and tried to email it to relatives. Not a success! Taking out the jpegs made no real difference to the size of pdf.

I finally realised something was wrong and downloaded a copy of Ancestral Author and tried that. It has a pretty gruesome interface but I eventually managed to generate a detailed descendant report about 150 pages long - but just 1.35 MB in size - including hyperlinks in the name index. I paid £24 to register the program to get rid of the watermark in the trial output. Perhaps I should send the bill to Calico Pie. Along the way I realised there were reports of similar (or worse) problems on the FHUG Forum but they don't appear to have reached any sort of solution. Where's all that wasted file space going?

[davepacey]

I have never had an issue with any reports in FH V6, but in V7 it is an absolute shambles, its not even consistent, sometimes I get a report with no text or images, just headers and footers, sometimes missing images, it gives up halfway through generating 1000 or so pages and crashes, if I refresh the report, it switches from portrait to landscape mode. This is just a few of the issues I have. I honestly wish I had not bothered to upgrade, I was hesitant, but thought it would get fixed, but I don't think it will.
I now find myself using Heredis as my family history program of choice, its reports are absolutely first class.

[Mark1834]

@Nalaho, welcome to the FHUG, and sorry that your first experience is a negative one. FH7 is printing its PDF output as an image file, so effectively a large photograph of what the printed page looks like, rather than just the contents and letting the PDF software create the page.

It’s a major bug in FH7, and I’m sure that Calico Pie are working on it. Unfortunately, they’ve known about it for some time, so it doesn’t look like an easy fix.

The temporary workaround is to save the report as an RTF file. Import that into any modern word processor and create the PDF from there. You may have to tweak the layout, as RTF is not a faithful copy of what you see in preview, but it’s the only option at the moment.

[tatewise]

@Nalaho, please update your Profile to show you are using FH V7 and not FH V6.

[Mark1834]

I've been exporting some reports this morning, going via an RTF file. Mostly, it has worked well, and having the file open in Word enables me to tidy up any inelegant page breaks or similar issues. One largish report reduced from 43 MB to 1.2 MB, so no problems at all with file size.

Curiously, I have come across one Family Group Sheet that just won't export or print as PDF from Word. Print with any PDF driver, and it just closes the print dialogue without printing, and saving as PDF gives me the unhelpful message that it "failed due to an unexpected error" .

There's nothing unusual that I can see in either the contents or size of the report, so I'll play with it a bit more later today and see if I can tie down the rogue element. Direct PDF save from FH is fine, apart from the huge file size.

[Mark1834]

I think I know what the problem is, and it's not good news.

My FGS Report is a compilation of 4 related families. If I exclude one family from the report, it behaves correctly. If I generate a report just for the problem family, the RTF file is stops after the first page of sources, and won't save or print to PDF in Word.

This is a new family, and I have entered all the census sources with tabular text from source, about a dozen in all. FH seems incapable of saving a document with this number of tables (perhaps the complexity of having so many tables embedded in other tables in the RTF doc?). Deselect "Text from Source" in the report options, and everything behaves itself again.

I'll raise another bug report with CP, but it looks like even the workaround is bu****ed in FH7....

[LornaCraig]

Mark, what happens if you try to create a Record Detail - Sources report for those sources? Presumably that also fails? But experimenting with the number of sources selected might help to work out how many tables FH can cope with in a single report.

[AdrianBruce]

... FH seems incapable of saving a document with this number of tables (perhaps the complexity of having so many tables embedded in other tables in the RTF doc?). ...

Tables inside tables? Oh crikey....

Speculating just to try and link bits: Does this sound like the Rich Text Control for Windows that Nick Walker referred to a few days ago in your "Rich text and table display limitations" thread? Maybe it looks fine on the screen but turning into a PDF file isn't working (hence CP writing images not text PDFs) and the work round for writing RTF files (from an RT Control!) appears problematic in certain circumstances....

[paultt]

A some time ago in my days of writing php scripts, we used to use a fpdf.php system to generate pdf reports which we could distribute to users. One of the issues that we had to overcome was the use of TTF fonts which were not included in the standard fphp distribution (courier, helvetica and times). We had to 'Add_font('fontname') the other fancy fonts in our scripts for the extra fonts, so that they would be embedded into the output pdf, and therefore could be read by any pdf reader or browser. The more fancy fonts we used in a script increased the size of the output pdf file. An A4 page with a couple of extra fonts and a few graphics would always end up being bigger than 1 mb in size. I wonder if the new fancy text editor in FH, which seems to list ALL the Windows fonts as available, is inadvertently adding them all into the pdf output, whether they are used or not, and thereby causing the 'bloat' in the large size pdf's.
Just a thought.

[NickWalker]

A nice theory, but I seem to remember the PDFs produced don't have selectable text and appear to be just image files. I would have expected if fonts were included that the text would be selectable?

[Mark1834]

I was wondering if it might be related to the width of the tables, particularly for 1891 onwards, where they tend to well overspill the width available. That gives another problem, where it’s just impossible to display the later census tables neatly in portrait orientation with any reasonable size font.

My plan at the moment is to strip out all the tables that I have added in FH7 (luckily not too many) and go back to plain text. That should simplify the RTF output considerably, so hopefully make it more stable and predictable.

I’m rapidly running out of FH7 features - templates (kills compatibility), DEA-driven data entry (not needed), tabular rich text (can’t output reports) - but I’ll stick with it for a bit longer...

[Mark1834]

My hunch was correct - if I make sure that every table fits within the available space, the RTF file outputs correctly. This 1911 Census output is not exactly practical though. I could use more abbreviations, but that's moving away from being a true transcript...

Capture.PNG (17.14 KiB) Viewed 4632 times