mdpdf icon indicating copy to clipboard operation
mdpdf copied to clipboard

font-size not respected in generated PDF

Open rask opened this issue 6 years ago • 7 comments

I'm using mdpdf to generate documents with a custom CSS stylesheet. In my CSS, I have

body {
    ...
    font-size: 20pt;
    ...
}

and I invoke mdpdf as follows:

$ mdpdf document.md --style styles.css

No matter what I do, the font-size in the rendered PDF stays the same (looks like 8pt or something). The body has the only font-size declaration so nothing is overriding it as far as I can tell. Is there any way to debug the process between .md import and .pdf export?

My mdpdf version is 2.0.2 and I am running Linux Ubuntu 18.04.

I need to check the rendering on my home computer, because it worked OK the last time I used it there.

Let me know if there is anything you want to know.

rask avatar Mar 05 '19 12:03 rask

Okay, found out about the --debug switch.

My problem stems from the magically injected CSS block:

<style>.markdown-body {
    font-size: 11px;
}

img.emoji-img.emoji {
  max-width: 11px;
  max-height: 11px;
  vertical-align: middle;
}
</style>

Where that .markdown-body class is magically applied to my document, overriding my font-size definition.

Any idea how this can be disabled (I prefer not to add body.markdown-body to my stylesheet as it may be used elsewhere as well)?

rask avatar Mar 05 '19 12:03 rask

Hi there @rask, you're totally right about the additional css that's added. This is a very thin layer of bootstrapped css which is added to make all pdf's display reasonably with minimal css changes. I think the default fontsize is something like 28 which starts to look really weird and makes the user experience a bit naff.

The default css can be disabled via the JS api but not by the cli because we try to keep the number of cli flags down and this hasn't been an issue for anyone in the past. I'd be open to adding it if it's causing substantial difficulties but it seems like it's a fairly easy thing to fix with better documentation in the project.

I think this is a documentation issue rather than something than an implementation issue, as you said you had to debug to understand the way the css works which isn't okay but the default settings seem to be convenient for the vast majority right now so I'd be reluctant to change it too much.

elliotblackburn avatar Mar 05 '19 13:03 elliotblackburn

I see. Thanks for clarifying. I filed this issue mainly because this did not happen on a version I used a few days back on my other PC, and now it caught me off guard. I agree: making it clearer in documentation is probably the sanest fix for this.

rask avatar Mar 05 '19 13:03 rask

Fantastic, thanks for your input @rask, I'm always open to issues being opened, especially around the UX.

I'll see about adding some documentation this week, I just got back from a holiday so I'm a bit behind so it might take a day or two.

elliotblackburn avatar Mar 05 '19 13:03 elliotblackburn

A though crossed my mind just now: would it be silly to use html instead of body for the injected font-size? I presume only a few CSS authors would set their baseline font-size into html instead of body? Or is there some technical limitation to using html for this?

rask avatar Mar 05 '19 13:03 rask

I'll be honest off the top of my head I can't completely remember but I'm pretty sure it's because of the default styling generated that was used. The generator takes styles from github's markdown renderer and builds a css stylesheet out of them and that assumes a top level class of markdown-body. So I could go through and edit that css file to do this but if we want to add any pre-processing to the html in the future it would be nice to know the styles added to the markdown are siloed off against a specific class.

That way we could add all sorts of pre-processors into a page and we'd be able to say "this class and anything within it is user space".

So it would be possible, but it would require editing the css by hand and it's quite a large file that has been auto-generated. When updating it in the future (if github change their styles for example) we'd need to re-edit that as well and it may not be a simple thing to automate. This also provides a nice way to add a barrier around user space styles.

I wouldn't be against it if someone wanted to add a PR for automation of the css manipulation but looking at it, it wouldn't be simple.

elliotblackburn avatar Mar 05 '19 14:03 elliotblackburn

Late to the game I know, but a quick workaround is to use CSS's !important hack in your stylesheet to force the value:

body {
    ...
    font-size: 20pt!important;
    ...
}

ABelliqueux avatar Jan 29 '24 14:01 ABelliqueux