Print styling should include page break instructions so headings stay with content and components aren't split across pages

[ApolonTorq]

Regardless of the planned support for "single book" retype output, browser print functionality can be used to generate a pdf for a single document right now. It works in the browser as expected except that headings can be split from their related content and some components get split across pages when they shouldn't be.

As a workaround for my immediate need, the style entry below was defined at runtime using the developer inspector in Chrome. It illustrates the need for figures, images and column components to avoid breaks and that headings should be kept with the content that follows immediately. Useful html output mods would include providing a class to be used by divs that wrap headings and id generation to allow for numeric prefixed headings.

As an interim mechanism for complete print/book support, would you consider adding support for a retype.json specified:

• html file that gets automatically injected into the generated html header.
• folders or files that get copied to the output resources folder.

It would also allow for a variety of customizations and work arounds that are available to retype users without a request for a new feature.

<style>
    figure, img, .docs-columns {
        display: block;
        break-inside: avoid;
    }

    #docs-site-header, button.fixed {
        display: none;
    }

    [id='3d-rendering'],#data-bricks-and-cosmosdb {
        break-before: page;
    }
</style>

[ApolonTorq]

Alternatively, how about including tailwind based customization support as retype.js specified configuration?

[fabriciomurta]

Hello, thanks for the report! That's looks like a very nice feature to allow easy and nicer PDF-printing of articles of interest.

• html file that gets automatically injected into the generated html header.

You want the HTML injected as a way to add a common header / watermark to the pages to be printed? I mean, an HTML specific to be injected when the page is being viewed in "printer friendly format"?

• folders or files that get copied to the output resources folder.

If you create a resources folder in your Retype input one, then these files will be delivered by Retype -- and even further, they will always be included in the build process.

In fact, anything included in any of the key folders listed in the end of the include section in Retype documentation is copied over, any files always included, without the need of extra configuration.

Alternatively, how about including tailwind based customization support as retype.js specified configuration?

This sounds like a powerful feature (bringing along big responsibility). But maybe it'd come to waste when #85 materializes?

[ApolonTorq]

If you create a resources folder in your Retype input one, then these files will be delivered by Retype -- and even further, they will always be included in the build process.

I didn't realize this. Its probably worth noting this in the include section of the retype documentation.

In fact, anything included in any of the key folders listed in the end of the include section in Retype documentation is copied over, any files always included, without the need of extra configuration. Thanks for mentioning this.

I added default.htm to the include list and the retype document server honored displaying default.htm in preference to index.htm as presumably a convention. This has allowed me to add a custom print.css stylesheet. Yes, I understand that the default.htm will have to potentially be replaced with a new one for each retype tool release.

Any chance of supporting the ability to add custom entries to the html header? Its not just about print work arounds. Its more about having some flexibility. Yes, I understand that with great power comes great responsibility. From a retypeapp perspective, a policy that advanced css/html-header related support questions can only be handled through community responses or commercial support would be one way of handling the potential support overhead of giving retypeapp users a sharp knife to work with.

This sounds like a powerful feature (bringing along big responsibility). But maybe it'd come to waste when #85 materializes?

Yes, somewhat. However, resolving minor issues like this earlier rather than later makes it easier to convince management to pay for the commercial version when it comes time to having that conversation :smile:

[geoffreymcgill]

Any chance of supporting the ability to add custom entries to the html header?

as of Retype v2, you can add custom values into the <head> section of every page by using the _includes/head.html and _includes/head-top.html files. See https://github.com/retypeapp/retype/discussions/282#discussioncomment-2343005.

Hope this helps.