* V7 PDF creation very slow, creating huge files

[Mark1834]

I've had another go at getting an acceptable format for the 1911 Census that FH can output before giving up on tables. With a bit of abbreviation and combining columns I can get to something that is at least workable. I've copied the information in my old narrative style below the table, and which is "better" is personal preference.

Capture.PNG (88.12 KiB) Viewed 4208 times

[AdrianBruce]

Mark - thanks for this (from v6-land).

Do you have a tentative summary about the cause of the table related issue? Specifically do you think it's tables within tables that cause your problems? (As I understand it, the RTF pages appear to be laid out in tables so any user created table in text is a table within a table.)

Or is it when the user created tables are wider than the sheet of paper (for want of a better term)?

[NickWalker]

FH7 rtf doesn't allow tables in tables (in the rich text source, notes, etc).

[tatewise]

It is the saved RTF files that use tables to format the Report sections (and has always done so) but now a rich text table sits within those RTF file tables, i.e. table within table.

[AdrianBruce]

It is the saved RTF files that use tables to format the Report sections (and has always done so) but now a rich text table sits within those RTF file tables, i.e. table within table.

Thanks Mike - that's what I was trying to get at, though I hadn't got it as precisely defined as you just did.

So the question then is whether a (user-created) rich text table within an RTF table in, or destined for, an RTF file is a problem automatically? (bearing in mind, so far as I can see in v6, that not all text in an RTF file is laid out in an RTF table)

Or whether the issue is when the (user-created) rich text table is "wider than the page"? Mark certainly seems to imply that this causes a problem but I wasn't sure about the user-created rich-text table within an RTF table...

[Mark1834]

Simple "tables within tables" appear to be ok, as per the screen grab below. My conclusion (and what I reported to CP) is that the overspill kills output, not the embedded tables. I've converted all my census sources back to plain text, but will keep simple tables for this type of two column output.

Capture.PNG (12.89 KiB) Viewed 4166 times

[tatewise]

The layout of ISR and FGS reports were very different for me using both Microsoft Print to PDF and Nitro PDF Creator.
The fact details were in an odd bullet list format and the media image resolution was poor.
I can attach PDF files if interested.
However, they are better than nothing and are searchable text.

I was replying to Helen's posting suggesting to Save As HTML and in browser to print to PDF.
But her posting has vanished, maybe because Mark posted at the same time?

[Mark1834]

Yes, I've just tested HTML output in both Chrome and Edge, and layout is corrupted. I suspect Helen has tested it as well

Now that I've got rid of wide tables, my favourite option at the moment is to go via RTF. That gives good opportunity to tidy up some of the formatting (untidy page breaks etc), but the trade-off is the usual difficulty in Word of controlling the precise page layout when you have multiple images. I suspect that the preferred option will depend on what type of report output you have, and how complex it is.

[ColeValleyGirl]

Mark, the only problem I had was that there weren't any page breaks (hence deleting the suggestion). No corruption.

[NickWalker]

Personally I think that as FH 7 has only been out for less than 2 months, I'm going to assume that at some point CP will resolve these issues with reports and tables being too wide, etc. and so I'm going to carry on using tables and rich text. If a long period goes by without a solution (which I think/hope is unlikely) then I'll reassess that and it would be relatively easy to create a program/plugin to convert the rich text data back to plain text again if need be. I don't have any desperate need to produce any reports currently.

[AdrianBruce]

.... My conclusion (and what I reported to CP) is that the overspill kills output, not the embedded tables. ...

Thanks Mark

That warns me not to go down the route of over-wide tables (out of gauge as we said on the railways). I know that I'm quite liable to enter data without really thinking how to get it out - my typical failing with Excel...

I did hope that tables of a couple of columns would be ok, as it appears to be.

[tatewise]

Hele, my PDF had perfectly good page breaks. It was other formatting that was the problem.

[Mark1834]

Even when/if the flawed report driver is fixed, it doesn’t address the more fundamental question of how we get a wide table to properly display in an A4 portrait report, but that’s a topic for another day - bit like getting GWR to run on standard gauge..

[ColeValleyGirl]

Hele, my PDF had perfectly good page breaks. It was other formatting that was the problem.

Was this a PDF created by printing from an HTML file? For me, that was the only problem. (Fonts might have been amiss, but nothing I couldn't solve with css.) However, the lack of page breaks was a show stopper.

[tatewise]

I used the FH Save Report As... > Web Page (HTML)... and agreed for it to open in my default browser (latest Firefox).
Then in Firefox, used File > Print... and in Select Printer chose Microsoft Print to PDF, etc, and hit Print button.
See attachments that have several page breaks, but the bullet lists corrupt the layout.

[ColeValleyGirl]

Mike, no doubt the formatting issues depend on the reports you chose -- I was looking at a Narrative report.

The page break issues I found only materialised when you generate a report for multiple individuals.

As we're both agreed for different reasons that it's not a viable workaround, let us not waste any more time on it.

[tatewise]

I disagree, for Narrative reports, it works quite well, and it is in searchable text format.
It is far better than the blank pages I get that FH produces when saved directly to PDF.

The missing page breaks between separate reports is a bug in Save Report As > HTML that exists in FH V6 too.
The page breaks within one say Descendant by Generation report are present and correct.
In FH V7 it also omits the Bibliography, so that is a new bug.

If the Chrome browser is used then the citation superscripts are active hyperlinks in the PDF file.

[AdrianBruce]

... it doesn’t address the more fundamental question of how we get a wide table to properly display in an A4 portrait report, but that’s a topic for another day ...

Definitely another day - but I would like to squeeze in this thought - that we first need to think what an over-wide table should look like in such a report. I tried an over-wide table in MS Word and the excess stuff just vanishes off the side of the "paper". The only thing that I can say at the moment is that FH should fail gracefully, if fail it does.

[ColeValleyGirl]

I disagree, for Narrative reports, it works quite well, and it is in searchable text format.

No, we agree -- I was saying Narrative reports don't suffer the formatting problems, only the page break issue.

And the page break issue is within a single report, not between separate reports. Printing from the HTML version (because HTML doesn't have page breaks) results in multiple individuals in the resultant PDF appearing on the same page, when they didn't in the original report. See attached.

[shoshk]

Helen, you may be able to take care of the page break issue via css.

[ColeValleyGirl]

Shosh, I know, but it means it isn't a viable workaround for many people.

Plus, I don't need the workaround -- I can print to PDF from FH without difficulty, and use NitroPDF to convert the image to searchable text.

[Mark1834]

A common report I prepare is an extended Family Group Sheet, consisting of FGS reports for a principal family and all their children (so anything from one to around a dozen separate reports as one document).

I've been experimenting with saving this report as an RTF file, then using a VBA macro in Word to format it exactly as I want (margins, position of header and footer, font, paragraph spacing, stopping all table rows from splitting between pages, etc). It works really well, and it becomes a simple matter to scroll through the formatted report and quickly tidy up any odd page breaks. Saving it as a PDF from Word typically gives a file of only 500-600 kB for over 30 pages, including a lot of thumbnail source images.

The final document looks better than the PDF produced directly from FH, so I may carry on doing them this way even when the PDF routine is fixed.

[Mark1834]

Curious observation time - I'm sure I checked this when I first installed version 7.0.2 to see if it had been fixed, and it was just as before, with report PDF files coming out as images. I've just tried it again, and every report type that I've tried, with any PDF printer, is now completely blank. Charts and diagrams are still printing normally to PDF, with fully selectable and searchable text.

Not a problem at the moment, as I'm happy with going via RTF for the reports I produce, but just a little odd.

[tatewise]

Mark, are they 'completely' blank, or just have headers and footers, which is what I've had all along?
Maybe it depends on some Microsoft Windows RTF library confabulation?

[Mark1834]

I’ve also had just headers and footers sometimes, but these are completely blank!