Stream: IG creation
Topic: printing IG pages
Jose Costa Teixeira (Dec 28 2020 at 17:45):
Is anyone printing (or expecting/needing to print) some IG pages?
Jose Costa Teixeira (Dec 29 2020 at 16:59):
I'll ask anyway: currently if we try to print a page from an IG, we get the whole thing - header, footer, etc.
Would it be interesting to at least define a print area so that we only print the central content?
David Pyke (Dec 29 2020 at 17:01):
If your use case requires printing, then it would be better to create a Word doc from the content and have that available
Jose Costa Teixeira (Dec 29 2020 at 17:21):
ouch. I don't see how that could be possible. IG exporting a word document?
Jose Costa Teixeira (Dec 29 2020 at 17:21):
Personally, I'm just trying to save on toner whenever I print something from an IG
David Pyke (Dec 29 2020 at 17:30):
I wasn't suggesting the IG did the work, I suggested that you take the markdown/xhtml and create it manually.
Jose Costa Teixeira (Dec 29 2020 at 17:47):
sorry, my question was if it would be interesting to update the template so that we'd have a print area
Jose Costa Teixeira (Dec 29 2020 at 17:47):
(i should have explained it better)
Jose Costa Teixeira (Dec 29 2020 at 17:50):
Create documents manually from xhtml doesn't seem civilized. Perhaps copy-pasting from a browser would be barely acceptable if there's no alternative
Frank Oemig (Dec 29 2020 at 18:30):
What about media css for printers? It should be possible to do that by updating the template, I suppose
Jose Costa Teixeira (Dec 29 2020 at 18:36):
@Frank Oemig yes, that is what I was experimenting with locally, and I was wondering if that is a good addition to the template
Frank Oemig (Dec 29 2020 at 18:37):
I would say yes. The question is whether we can mark the ROI?
Jose Costa Teixeira (Dec 29 2020 at 18:40):
the template would have to define a fixed region, I think.
When I played with it, I basically included all the page content - i.e. except header, menu, and footer
Elliot Silver (Dec 29 2020 at 19:13):
What's the downside to doing this? If people want to print, it's helpful, if they don't want to print, they don't notice it.
(For clarity, we're talking about printing a single IG page, not somehow creating a paginated completed IG, right?)
Lloyd McKenzie (Dec 29 2020 at 19:49):
The challenge is knowing what people will want to print. For some, the header and footer info is noise. For others, they'll want it. (Personally, I don't understand a desire to print at all... :>)
David Pyke (Dec 29 2020 at 19:56):
I have the source pages to print if I really want to and I'll screen shot the views if I really want to print them. By why kill trees?
Grahame Grieve (Dec 29 2020 at 19:57):
carbon sequestration
John Moehrke (Dec 29 2020 at 19:57):
everyone (should) already know how to print from their browser.. so I presume you are asking about how to create ONE complete printout of all the relevant content in an IG. Some of that content is not worthy of printing, or atleast not worthy of printing without context. Further there are some things that clearly would need to appear before others.. And there would need to be shorttened (like the TOC).
John Moehrke (Dec 29 2020 at 19:59):
some pages in an IG are referenced from many places, but should only appear in a printout once. some pages won't appear except as linked from elsewhere. .
Lloyd McKenzie (Dec 29 2020 at 19:59):
We've talked about the possibility of creating a template for a printable IG - one that would produce a PDF or equivalent. There's some thought that certain regulators might require this. However, we haven't put any energy into doing this because a) no one's jumped up and down and demanded it (or put any resources towards making it happen); and b) we don't believe that printed layouts like PDFs are nearly as useful to implementers as a web-based presentation, and our objective is to make things as easy as possible for implementers.
Jose Costa Teixeira (Dec 29 2020 at 20:08):
this is why I wanted to gather feedback. Adding a printarea is simple but it's one flavour for all.
"Print" - capture a snapshot of part of the content so that it can be put in some other documentation
Jose Costa Teixeira (Dec 29 2020 at 20:10):
Elliot Silver said:
(For clarity, we're talking about printing a single IG page, not somehow creating a paginated completed IG, right?)
Right. Just making sure that when you do "print", it will exclude the header and footer
Jose Costa Teixeira (Dec 29 2020 at 20:13):
John Moehrke said:
I presume you are asking about how to create ONE complete printout of all the relevant content in an IG.
No, that would be a super fancy print-ready template.
Jose Costa Teixeira (Dec 29 2020 at 20:13):
Adding a print-area option is 10 lines of code per template
Jose Costa Teixeira (Dec 29 2020 at 20:14):
Grahame Grieve said:
carbon sequestration
Plus making some ozone if you have a laser printer :)
Lynn Laakso (Jan 04 2021 at 16:09):
Just to touch on this, when we register a normative standard with ANSI we have to provide a PDF. A printable format would be easier for me... Collating PDFs for registering the normative FHIR standard was a pain...
David Hay (Jan 07 2021 at 03:35):
Just out of interest, how did you do it? The spec is big... Or was it only the normative parts?
Lynn Laakso (Jan 07 2021 at 13:32):
mercifully, only the normative parts, page by page print to pdf.
Annatina Foppa eHealth Suisse (Apr 20 2021 at 06:53):
I face the same problem, having the Swiss regulation asking for PDFs of the specifications. Therefore I would also be interested if somebody comes up with a simple solution. @Lynn Laakso could you show me one of the examples how you did it for ANSI?
Lynn Laakso (Apr 20 2021 at 16:10):
for public consumption and posterity: Grahame created a page that summarized the normative components and I went through the list (e.g. Patient Resource) and those components and printed the html pages as pdf, and concatenated them all together. I did not include the trial use or informative material.
Jose Costa Teixeira (Apr 20 2021 at 16:22):
@Lynn Laakso do you have a link to the PDF just to see how it looked like?
Carl Leitner (Apr 20 2021 at 16:43):
Same need for a few projects I am working on
Lynn Laakso (Apr 20 2021 at 16:53):
No I sent it to Annatina privately; it's not a published document.
Lynn Laakso (Apr 20 2021 at 17:59):
OK you can see it at www.hl7.org/documentcenter/private/standards/Ansi - FHIR v401_Patient.pdf
Oliver Egger (Apr 21 2021 at 06:37):
for art-decor cda projects prince scripts were used to generate pdf's. @Jose Costa Teixeira would maybe a specific jekyll template work together with prince as it is described in Generating PDFs?
Jose Costa Teixeira (Apr 21 2021 at 06:47):
I don't understand where this procedure gets the files, but this looks like "just" passing the html through prince and adding some CSS on the way. that should not be too hard to add to the template (it doesn't have to be a specific template if those CSS are only there to be used by Prince).
Jose Costa Teixeira (Apr 21 2021 at 06:48):
Yes, @Oliver Egger that site is what inspired me to look at other themes
Jose Costa Teixeira (Apr 21 2021 at 06:56):
I think this would still need to separate the header/footer so that we don't print them. This can be done in a few ways:
- Use the print css style as @Frank Oemig mentioned just to enable something without many changes to the template
- Add a new jekyll theme that better separates the header/footer from the content. This is not the easiest for me...
- Pick up the content from the publisher temp file and do something with it (maybe xsl:fo or something) - this would be more radical
When I first asked, i was looking at option 1. because lazy
Lloyd McKenzie (Apr 21 2021 at 15:58):
One of the issues with enabling printing to PDF is that more publishers will do it - and that's generally a disservice to implementers. (Implementing FHIR from PDFs sucks.) So we should be cautious about pursuing this without a really compelling reason. (And ensure that enabling it requires reading warnings about the disadvantages and the importance of having a web-navigable IG in parallel.)
Carl Leitner (Apr 21 2021 at 16:02):
one example: WHO is only allowed to formally publish PDFs. that causes a documentation production challenge especially if we want to not have two documentation pipelines. in cases like this, the formally 'published' PDF should very quickly push implementers to the navigable version.
John Moehrke (Apr 21 2021 at 16:02):
would rather have a tool that understands our layout, can follow the table of contents, and just PDF the publication it is pointed at. This would not be part of the publication, but rather a tool that could be pointed at a publication.
Oliver Egger (Apr 21 2021 at 18:59):
The compelling reason is just for the law in our case. Having a "document" version of a specification helps in addition for archival and certification. Making a pdf out of a website is always a compromise, but maybe with the hints of @Jose Costa Teixeira a way could be found before we are assembling browser save as pdf pages together by hand ...
Jose Costa Teixeira (Apr 21 2021 at 19:13):
Indeed. ISO, WHO, MoHs seem to need a PDF document to be put in a document management system or any other repository. For these we may try to do something.
Jose Costa Teixeira (Apr 21 2021 at 19:13):
My Requirements list
R1 : Minimal effort to implement this
R2: for PDF producers, Consistency is good, low effort is nice to have - people only make PDFs once in a while, and may include manual work anyway, so as long as the PDF production is within civil limits, a bit of manual work may be tolerable
R3: Choose (and add) the content to make sure that readers always go back to the html online version.
Jose Costa Teixeira (Apr 21 2021 at 19:15):
John Moehrke said:
would rather have a tool that understands our layout, can follow the table of contents, and just PDF the publication it is pointed at. This would not be part of the publication, but rather a tool that could be pointed at a publication.
Agree this is not part of the normal publication process so no need to fully automate.
"A tool that understands the layout" - I assume/hope that the only tool that understands anything here is the user. (Navigating the layout and deciding what is to be in or out - that can be a user thing)
Jose Costa Teixeira (Apr 21 2021 at 19:16):
Simplest (and my starting point) is to add CSS that makes the header/foottter non-printable
John Moehrke (Apr 21 2021 at 19:19):
the IG publisher does produce a well formed table of contents. that is what I was refering to.
John Moehrke (Apr 21 2021 at 19:20):
presumably the order of pages listed on the table of contents is also a good order to capture the pages into a PDF
John Moehrke (Apr 21 2021 at 19:20):
vs trying to follow all links on a page.. that seems would end up in a bad solution.
Jose Costa Teixeira (Apr 21 2021 at 19:42):
The ToC is html, not the easiest to use for automation.
Jose Costa Teixeira (Apr 21 2021 at 19:43):
We could consider using the source that creates the ToC to do it.
John Moehrke (Apr 21 2021 at 19:44):
more useful than anything else we already have.
Jose Costa Teixeira (Apr 21 2021 at 19:44):
I.e. the IG itself, or the Composition if we get that
John Moehrke (Apr 21 2021 at 19:45):
you template gods can do far more than we mortals can ever aspire to.
Jose Costa Teixeira (Apr 21 2021 at 19:45):
I like the idea of reusing the content. I think it should be balanced between requirements 1 and 2 above.
Jose Costa Teixeira (Apr 21 2021 at 19:47):
Besides we also have discussed the possibility of changing the way the section numbers are generated. Perhaps that would affect tha
John Moehrke (Apr 21 2021 at 19:48):
there is also some discussion of next/previous navigation
Jose Costa Teixeira (Apr 21 2021 at 19:49):
In other words, css is simple and likely to be useful. Automation the use of toc to assemble a document may be a long(er) discussion which has more dependencies and impact
Jose Costa Teixeira (Apr 21 2021 at 19:50):
Thinking of this, it may actually be good to put this on the back of the effort to use Composition to generate ToC
Grahame Grieve (Apr 21 2021 at 20:39):
I would have thought something like https://cloudconvert.com/save-website-pdf would be the way to sort this
Jose Costa Teixeira (Apr 21 2021 at 21:17):
I presume that would print the header and footer (unless we fix that). Also would it print the tabs (diff, snapshot)?
Grahame Grieve (Apr 21 2021 at 21:18):
no. that's tricky but that's why there's an 'all' tab - default to that
Grahame Grieve (Apr 21 2021 at 21:18):
you don't really care what it looks like anyway. it's for legal compliance, not actual useablity
Jose Costa Teixeira (Apr 21 2021 at 21:21):
right, so we need to remove the other tabs and print the "all" tabs
Jose Costa Teixeira (Apr 21 2021 at 21:24):
Should we create a wiki page to take notes on this?
So far we have (I think):
- Only print the All tab;
- Print the following tabs: JSON?/XML?/Examples? History?
- Print the header and footer?
- ToC?
Oliver Egger (Apr 22 2021 at 05:52):
+1 for a wiki page, cloudconvert looks nice, but does not follow links from a toc as far as i have tried
John Moehrke (Apr 22 2021 at 11:12):
on an artifact page.
- Content +All
- Detailed Description
- Mappings
I would not think that XML, JSON, or TTL tab are useful in a PDF
John Moehrke (Apr 22 2021 at 11:13):
Examples is not clear why not, but would also just be a list of things not included. I guess knowing the name of an example is useful for documentation referencing sake
John Moehrke (Apr 22 2021 at 11:14):
CapabilityStatement - seems these are just flat. right?
John Moehrke (Apr 22 2021 at 11:16):
also flat are operations, valuesets, codesystems, extensions, search parameter,
Last updated: Apr 12 2022 at 19:14 UTC
