Computeractive 639 (31 Aug - 13 Sept 2022) p.age 16
I wonder what lead Ted Green to believe Gramps has a limit in the page size to either A4 (210x297 mm) or 98 pages?
The page size is only limited by the version of PDF supported by your OS.
1 Like
Not completely correct, it is limited by the PDF version that the pdf writer library that Gramps or the Gramplet use (or of course any other pdf library a writer software would use), if Gramps use a PDF library that only support PDF version 1.4, there will be arbitrary limitations in the dimensions of the PDF, even if you have other software that support reading or editing PDF versions up to 1.7.
The main limit using .pdf or .svg output from gramps will be what physical size your local “high-stree printer” can handle. In my case, my local plan printing service can easily generate a physical print for me at a page width of the short dimension of up to A0 (i.e. 841mm wide). Subject only to file size and machine memory limitation, they can print nearly unlimited length (I have printed trees of up to 6 A0 tiles long). The other practical limitation is cost, especially if you have color-coded various of the text objects, strokes and/or fills. Like Brian, I am mystified why yorkshire_lad thought there was any constraint in gramps to “98 A4 pages in PDF”. Even if there are indeed limits in some of the libraries on some platforms, I suspect that finalizing the tree in .svg in an appropirate editor, before exporting to .pdf, can both optimize how much info fits onto whatever virtual page size you decide to use (because you can relocate some of the few objects sitting in otherwise little-used physical space on one side or another of the tree), and tweaking all manner of colours, fonts, etc for readabiity, can get around most OS or library constraints anyway. An editor like inkscape brings pdf libraries with it that in my experience are very robust, though I don’t have experience with it on platforms other than the Win10 I use. (This assumes when you refer to “tree” you mean one of the gramps “Reports > Graphical reports” trees, since any of the “Reports > Graphs…” which generate via graphviz are impractical to optimise in an .svg editor–these may still work well to a long banner printer, but you don’t get any capacity to tweak them in svg because nearly every object is a glyph.)
The handling of PDFs where custom page sizes exceed 200 inches is problematic on Windows.
If Acrobat Reader X is the default helper application, it gives the impression that Gramps failed to write data without any warning. The viewer shows a blank page and then claims the page width & height properties are only 200". But this is viewer failure, not a Gramps report generation failure.
PDF Architect 5 shows the real content and page size accurately.
What happens on Linux & macOS?
Note: My test is generating a 211"x211" PDF Fan Chart on the home person of Example.gramps and opening by default. (This unappealing chart isn’t scaled to fit the space properly nor are the labels scaled. But those are separate issues.)
1 Like
On MacOS, I generated a 211 inch x 211 inch Fan chart as described. Adobe Acrobat (free) is limited to 200x200 inch PDF. You can see from the file info, the PDF is 211 inch.
So same behavior as in Windows - gramps writes file correctly but the free Acrobat Reader is where the issue resides.
1 Like
There is a free tool named “posterazor” which could help:
it’s available for Linux, OSX and Windows.
2 Likes
There’s a lot more to scaling than I had expected. You have to manually control everything to get a usable print. It doesn’t have an option to center the chart vertically. So you have to do that with the bottom margin.
Then you have to create a new reports style sheet and guestimate the font size scaling factor. This sample increased the point size from 9pt to 96pt. (It also required turning on the “Draw empty boxes” option before the penny dropped that the scaling of the chart was not content aware… it only considers how many Generations were chosen.
There are open source PDF readers like SumatraPDF available for most platforms, including Windows, that can handle extremely large virtual page sizes.
Vector editors like inkscape can handle any pdf page size too, and you can also do a lot of useful resizing and other formatting of objects within the page (as long as text at original page generation is rendered as text objects rather than as glyphs).
I gave up on fan charts a long time ago because reformatting them (other than very simple ones) is not practical due to the complicated variable geometry involved. But any chart type where the same scale factor can be applied to all or most objects of the same type in both the x and y axes can be extensively reformatted after gramps has taken care of basic positionng of boxes, connectors and text anchors to fit the design page. I almost always undertake significant rescaling, repositioning & reformatting of ancestor & descendant chart objects before distribution in pdf.
2 Likes
What happens on Linux & macOS?
I have used Gramps on Linux and macOS to produce relationship graphs up to A0 size. This typically produces a relatively small pdf file, which I get printed at a stationery shop. It all works fine.
This is not correct… SVG is vector graphic, e.g., the document size is of secondary importance. Same is with PDF files that is not bitmap graphic.
The PDF graphic “files” is in practice vector graphic, unless it is an embedded bitmap image. (Very simplyfied).
For PDF it is the dimension for the file format standards version that is the limit, not what your printer support… less than 1.6, lower dimensions are supported, 1.6 and over, near “unlimited” dimensions are supported.
If there is limitation even if the library support newer version of the PDF standard, those are hardcoded into the software, e.g. if the software only support writing to pdf in the format that your printer support, that is bad programming in the software, not a limitation in the format.
There is another limitation, at least when exporting some reports, e.g. graphical reports, to the DOT format, and that is the DPI setting of the export, if more than 300DPI the export crash… I stopped testing it for other formats.
Regarding Inkscape and e.g. Krita, yes, their PDF and SVG libraries are really robust, I agree, and those are also updated regularly when new versions of the standards is released…
Yes, as I try to say, if the library used to write, print or open the PDF doesn’t support the newer versions of the PDF standard, you will get problems… or if there is artificial limitations hardcoded into the software…
I actually have no problems with that using Foxit PhantomPDF, and as long as the library used support the newer PDF versions, it also should support the larger dimensions, but as you write, it is a library/driver limitation… So if Gramps use a Python library that support the newest versions of PDF, and actually utilize that, e.g. save the file as version 1.6/1.7, the report will be written, and saved successfully in the actual dimension, but if you open the file in a viewer/software that doesn’t support the latest versions or have som artificial limits hardcoded, you will of course get into trouble…
But, in those cases, just open the PDF in InkScape or a pdf viewer that actually support the versions fully…
InkScape is also often more memory friendly than “PDF editors” for some reason…
I notice that Brian’s letter in reply to this has been published in Issue 641 (28 September - 11 October) on page 41. It includes a link to this discussion.
Thanks @emyoulation.
4 Likes
Good spot (I haven’t read my copy yet)
Here’s the item (from my copy of CA)
I also sent a note to the CA letters editor, saying there had been a discussion about the matter of pdf size written about in CA 639 on the gramps discourse group, and am delighted that they’ve printed the response from Brian and a url.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.