Family Historian User Group

I cannot find directions for inserting PDF or Doc documents into a "Books File"
Or, better worded, embed these documents into the Book format.
If I try to use View/Blank diagram, I only get the choice of inserting a TXT box or Picture, or Freehand Sketch.
Of Course I could convert my documents into pictures and add them, but i think I'll loose pixel resolution in the process and the final printout will suffer.
FH Help does not show anything in the above subject, can you help, or have a solution, you always seem to have a solution!
I did not do an exhaustive search of the knowledge base, except for the exact wording used above.

FH does NOT support PDF or DOC or Sound or Video media files, except via an external editor/player.
FH only supports Image Files such as JPEG or PNG within Reports and Books and Diagrams.

See how_to:v4:adding_multimedia#adding_other_media|> Adding Other Media that clarifies that position and refers to graphics products that will convert predominantly image PDF to graphics format. I suspect there will be little loss of resolution.
e.g. fhugdownloads:contents:irfanview|> Utility ~ IrfanView

If PDF or DOC files contain images, then they can usually be copied & pasted as separate image files.

Then those image documents will appear in the Media tabs and in Reports and Books.

In both PDF and DOC files, any text is better copied & pasted into Text From Source or similar FH transcript text fields.

The only alternative would be to use external editors to combine PDF documents together.

OK That clarifies everything.
In my case then I'll do as I planned, have a Free Text page refer to a supplement, that Supplement Page has its own contents and index to the addenda.
The supplement, will be integrated by the printer into the final bound book to the back of the book published by FH.
For the future 'wish list' this would be a nice added feature to your program, unless there is unforeseen problems I don't
comprehend, foresee, or understand at the moment.

You talk about 'your program' but remember I am just a user of FH like you, and this is the FH User Group.
The program author is Calico Pie, so report your 'wish list' to them. See how_to:about#problem_reporting|> Problem Reporting.

This topic has arisen many times before.
Calico Pie are in the business of genealogy software and not media viewers.
Where would the list of media files stop? PDF, DOC, DOCX, RTF, ODT, WAV, WMA, AVI, FLV, WMV, MP4, MOV.
I would rather Calico Pie develop the FH genealogy features and integrate with other genealogy products.

Given that the GRO now supplies Birth and Death Certificates in .pdf format there is an even greater urgency for FH to be able to display this format within the program without the need to load external programs and to display them properly in printouts and in books.

Those of us familiar with Apple computers are used to .pdf files being displayed seamlessly in a variety of apps, including multipage .pdfs in the Finder app (the equivalent of the Windows File Explorer), without the need to load other helper programs. Does anyone know if there are insurmountable problems on the Windows platform that make it either difficult or impossible for Windows programs to do the same?

Windows File Explorer can display any file types including PDF by opening them.

PDF (and other file types) can be displayed within FH by clicking the triangular Open in Editor/Player button or the file icon.
Those PDF GRO Birth/Death Certificates are easily converted to JPG/PNG image files.

What FH cannot do is incorporate PDF files into Report or Book documents (that may be output in various formats).

Gerry, are you saying Apple Mac can display PDF files without needing a PDF Viewer app to be installed?
Can such PDF files be incorporated into a word-processor document?

tatewise wrote:Gerry, are you saying Apple Mac can display PDF files without needing a PDF Viewer app to be installed?
Can such PDF files be incorporated into a word-processor document?

Yes that is right @Mike, in Finder (Explorer) highlight the file and press the space bar opens the file, (pdf, jpg, png, docx, doc, xls etc) in a viewable window BUT you can't do anything with what is displayed. No cut & paste for example. So in answer to your second no they can't be copied into a word document from this viewer.

It cannot be the case that Apple Mac can view EVERY file type, as there are too many proprietary file types (e.g. FH files).
It presumably only has built in viewers for popular file types.

So not significantly different to Windows where many file type viewers (such as Adobe Reader, etc) are installed by default?

Anyway, regarding this thread about inserting PDF into Reports & Books, the Apple Mac is no better?

It's worth mentioning that the PDF viewing feature mentioned only works directly in the Mac's 'Finder' (File Manager) application and is not automatically available to other native Mac applications, which simply launch the Mac's 'Preview' application (or whatever default PDF App is set) to view and edit media files in just the same way that Windows apps do; so this is a relatively small but useful enhancement in media handling in MacOS, but that, unfortunately doesn't (currently) carry through to providing the same capability to other native Mac applications.

There are several other media management features that have been implemented in MacOS for many years, but not (yet) in Windows, which I find far more compelling eg. the ability to be able to rename and relocate files, whether in use or not, without them becoming 'lost' by the program(s) that they are used by.

Mervyn

tatewise wrote:It cannot be the case that Apple Mac can view EVERY file type, as there are too many proprietary file types (e.g. FH files).
Anyway, regarding this thread about inserting PDF into Reports & Books, the Apple Mac is no better?

@Mike I didn't say it could display ALL file types but it does all those that I mentioned above and many more all without loading any viewers onto the system they are all handled by the OS, they are viewers only and don't allow any editing, cutting & pasting or anything else just viewing.

Running FH on a Mac does not give any advantages over running it on a PC as it is in a VM or emulator.

gerrynuk wrote:Given that the GRO now supplies Birth and Death Certificates in .pdf format there is an even greater urgency for FH to be able to display this format within the program without the need to load external programs and to display them properly in printouts and in books. ...

The essential problem with a PDF being shown in a book is - how big is it? A GRO Certificate kids you because you think it's easy - it's of known size so you just get FH to allow a space X big to show it. However - FH has no idea how big that PDF actually is in the general case - half a page, one page, 100 pages? So how, to take the simplest issue, can it work out the page numbering? It would need to open it up, calculate the page size, etc, etc. Not nice.

I just tried inserting a link to a PDF into a Microsoft Word document - I get the first page only, which provides a clickable link to the original PDF. So even MS doesn't attempt to show the whole of the PDF.

Now, none of this is insurmountable provided you can work out what you want to do - e.g. devote a whole page to just showing the first page only of the PDF? (And would this be what everyone wanted?) But it does illustrate that this is not as easy as showing a (shrinkable) JPG inside a box of known size.

If the pdf is only a handful of pages I convert them to jpg's and attach the images. This is no different than, for example, military records which can span many pages, each is shown as an image on Ancestry / FMP and I save all and attach them all as source images.

I get the feeling, perhaps unfairly, that some of you are allowing the operating system to limit your ambitions rather than finding ways to make the OS do what you want. There are plenty of pdf display programs aside from Adobe's products so it must be possible to achieve what is required.

As others have commented already the GRO pdfs are of known size and therefore, presumably, must have some code within them that the OS can interrogate to determine these dimensions. From my experience of exporting various multi-page presentations to pdf format these are also of a fixed size. So for these documents there shouldn't be any problem for the OS in determining the display area required and to be able to scale the document to fit the actual display space available eg A4. If I am correct - and I'm sure you will put me right if not - then it should not be a particularly difficult problem to display the contents of these pdf documents. I'm not sure why Adrian considers this "Not nice".

I am aware that some pdfs have pages of different sizes and orientations. Could FH not treat them as a series of single page pdfs and deal with each page individually?

Are there any pdfs that do not have dimensions? If so FH could reject them and put up a comment explaining why they cannot be displayed.

OK, guys and gals, now shoot me down!

gerrynuk wrote:So for these documents there shouldn't be any problem for the OS in determining the display area required and to be able to scale the document to fit the actual display space available eg A4.

Well if you want the OS to do this perhaps you should be directing this a Microsoft, Calico Pie will certainly not touch the OS. I'm with Mike on this one: "I would rather Calico Pie develop the FH genealogy features and integrate with other genealogy products."

Several postings seem to be missing the point as indicated by the Subject line.

FH has NO problem presenting ANY type of document (including PDF and DOCX) for which the OS has a suitable viewer.
For PDF the viewer does NOT have to be Adobe Reader, but any viewer the users prefers.
For DOCX the viewer does NOT have to be MS Word, but any compatible word-processor the user prefers.

What FH and the OS (both Windows and Mac) cannot do is embed a PDF (or various other file types) into a Report or Book.

The file size of a PDF (or for that matter a DOCX) gives no clue as to the number of pages.
It depends on many factors such as the Page Size (A0 to A6 say) and how much text and how many images it contains.
I have many of examples of quite small PDF or DOCX files with multi-page text, and much larger files with a one page image.
To discover such details and embed them within a Report or Book would require FH to have a PDF and DOCX file decoder built in, and similarly for all other popular file types.

davidm_uk wrote:

gerrynuk wrote:So for these documents there shouldn't be any problem for the OS in determining the display area required and to be able to scale the document to fit the actual display space available eg A4.

Well if you want the OS to do this perhaps you should be directing this a Microsoft, Calico Pie will certainly not touch the OS. I'm with Mike on this one: "I would rather Calico Pie develop the FH genealogy features and integrate with other genealogy products."

So how do open source pdf display programs interrogate the pdf dimensions?

For me this is and has for some time been an important genealogical feature as increasingly sources are being presented as pdf files: the GRO birth and death certificates are the most recent examples. I use the Medway City Ark (as it used to be called) and their records are now presented as pdfs. No doubt there are other examples that people have come across. Having to convert these to image files seems to me to be a superfluous step. Incidentally, any program used to convert from pdf to image file must know what size the resultant image should be so it must be able to obtain the image size from the pdf!

Those open source PDF and DOCX viewers and editors have invested a great deal of time & coding into understanding and rendering those document formats as published by Adobe and Microsoft. They are not interrogating just the dimensions, they are interpreting the entire document format specification.

So you are asking Calico Pie to spend their time & coding to replicate that capability for PDF (and how many other formats), and keeping abreast of new format developments, such as when DOC became DOCX.

gerrynuk wrote:... As others have commented already the GRO pdfs are of known size and therefore, presumably, must have some code within them that the OS can interrogate to determine these dimensions. ...

I would say that the size is known to us - but that size is not recorded in the PDF in any meaningful manner. I honestly think that there is no dimension data in a PDF. There is only text (or embedded images) plus a specification about what font, paper size, etc. Any dimensions only come from actually doing the "print". Ironically, of course, the image in a GRO PDF is already inside it as an embedded image file. The weird thing is why on earth these companies are using a PDF format, which is primarily aimed at recording text, to transmit the images that they already have as JPGs or equivalents!

gerrynuk wrote:...I'm not sure why Adrian considers this "Not nice".

My feeling is that by the time you've done all this, you've gone past the point of no return with your FH page numbering. If it's a JPG, it is sized there and then without reference to the contents of the file. Easy. If it's a PDF, it can only be sized by "printing" it. Then somehow FH has to capture all that and get back to its own page numbering.... And what if the PDF pages were in landscape A3 instead of the FH report's portrait A4? Who wins that battle? That's why I think it's not nice. There's a potential battle going on between the text from the FH report and the text from the PDF file, whereas the JPG file is already dimensioned and subsidiary - JPGs are supposed to be subsidiary.

It's my honest opinion that it's a hugely complex task - as I said, if Microsoft Word refuses point blank to show any more than the first page of a PDF, I can't expect Simon and his team to beat them. It's not a bad idea - it just worries the heck out of me how to do it.

tatewise wrote:Those open source PDF and DOCX viewers and editors have invested a great deal of time & coding into understanding and rendering those document formats as published by Adobe and Microsoft. They are not interrogating just the dimensions, they are interpreting the entire document format specification.

So you are asking Calico Pie to spend their time & coding to replicate that capability for PDF (and how many other formats), and keeping abreast of new format developments, such as when DOC became DOCX.

Clearly from what you say you are confirming that it is perfectly possible for FH to display pdfs without relying on a helper program. Calico Pie is a more than competent programming firm as demonstrated by the way FH has grown and developed over the years. If there is sufficient demand for a feature then they will try to provide it. Better provision for the display of pdfs has long been asked for and I am puzzled why it has not been provided. It cannot be the complexity of programming as plenty of programs to display pdfs already exist. I cannot believe that Calico Pie lack the competence of amateur programmers who have already surmounted the problems that you say exist.

As I mentioned in a previous post more sources are now being offered in pdf format alone and so the issue won't go away. I realise that Calico Pie may be reluctant to get drawn into this discussion but at least if it is aired on this forum then they will understand the frustration of many FH users and perhaps feel that it is time to respond with suitable programming enhancements.

As Adrian alluded to, the FH problem is rather more complex than just presenting a stand-alone PDF.
How does FH handle the conflict between Report/Book page size and PDF document page size, that may be very different?
How are Report/Book page numbers and PDF document page numbers reconciled?
Are PDF features such as Thumbnails and Bookmarks to be retained?
The list of conflicts to be resolved goes on and on...
Yes, it may be feasible with enough effort, but is it really what users want Calico Pie to devote their time to when there are straightforward workarounds for the majority of cases where the PDF is just one or two images. Personally there are more pressing long-standing issues in the Wish List.

Just as an experiment try printing to a real printer this PDF:
Henry VIII and the Break with Rome information sheet
I tried Adobe Acrobat Reader DC and Nitro Reader 5 and only a very limited set of options worked.
(Hint: The page size appears to be Legal 8.5 x 14 inches instead of A4 8.27 × 11.69 and does not auto-scale easily.)

I believe there is a lot of misunderstanding about the nature of PDF documents, the main one being that a PDF is just another 'simple' method of presenting 'images', i.e. similar to jpg, png etc., but, in reality, the format is far more complex; and is essentially, uneditable in its final production state.

A brief internet search on the positives and negatives of PDF documents easily produced the following extracted quotes:

"A PDF file is essentially an uneditable image of the original document. This is great is terms of security, but PDF fails as a collaborative format. If your PDF file is native, it is possible to use software to extract the information into a usable form. However, if you have a scanned PDF document, there is no way to easily convert it back to an editable form."

"
CONS
– it’s not free to edit PDF files;
– it’s easier to edit files in other formats than in PDF, because PDF files must be edited in specialized programs;
– it’s difficult to work with text in PDF files, because they are perceived as a picture.
"

Then there's the complexity of what can and might be included within a PDF document, which can extend from one to hundreds of pages, including text, images (in many and varied formats), sound and video. Then there is the original document format information including static page sizes, fonts etc. which is all embedded within the individual PDF documents and which is not editable without specialist PDF software; and possibly not even with such specialist software if the original document has been password protected by the author/producer.

Users of various software (including most genealogy apps) often seem to pose questions about why PDF content cannot be directly embedded with other PDF output produced by their chosen application, but no generalist software I have ever come across does so, which is probably why there is a plethora of PDF specific software available. Those applications concern themselves exclusively with viewing, working with; and producing PDFs; and generalist software (including genealogy apps) stick to what they are best at. The fact is that Microsoft, with all its resources and experience, has no application that can do, or can even come close to doing, what it is suggested Calico Pie should be able to achieve, which should convey that it is very far from being a relatively simple or reasonable expectation.

Mervyn

tatewise wrote:....
Yes, it may be feasible with enough effort, but is it really what users want Calico Pie to devote their time to when there are straightforward workarounds for the majority of cases where the PDF is just one or two images. Personally there are more pressing long-standing issues in the Wish List.

Just as an experiment try printing to a real printer this PDF:
Henry VIII and the Break with Rome information sheet
I tried Adobe Acrobat Reader DC and Nitro Reader 5 and only a very limited set of options worked.
(Hint: The page size appears to be Legal 8.5 x 14 inches instead of A4 8.27 × 11.69 and does not auto-scale easily.)

Your test pdf seemed to print without any problems. Just had to change settings to print in Landscape at 75%.

To answer your question I do believe it would be very worthwhile for Calico Pie to devote time to improving the display of pdfs in FH. With more and more sources now being presented in this format it is no longer acceptable for these documents to need an external helper program to display. Of course it is only natural that you have your own priorities for the future development of FH but I am rather take back by the vehemence with which you appear to be objecting to improved pdf provision. Surely it is for Calico Pie to make that judgement?

It would seem that Calico Pie have already made that judgement.

gerrynuk wrote:... I am rather take back by the vehemence with which you appear to be objecting to improved pdf provision. Surely it is for Calico Pie to make that judgement?

We're not objecting, we're just trying to set expectations by pointing out that it's virtually impossible to see how it can be done - not if the requirement is to simply display a PDF, any PDF, inside an FH report. As was said earlier up the thread, if Microsoft refuse to try to show anything other than the first page of a PDF, we'd be foolish to expect Calico Pie to do better.