MGerber wrote:Hi!
I have a simple span style to show letters or even words in keyboard design. I use a single CSS for all outputs. Each style is used in common (
Medium: (default)). Oh, and: Flare 2017 r3.
Code: Select all
span.Keyboard
{
border: solid 1px #dcdcdc;
border-radius: 4px;
background-color: #fffdf7;
padding: 1px 3px;
}
So, nothing really special here.
I use PDF output primarily. However, not all elements of this style are applied there. Background color and border are rendered as intended, the padding is ignored (see pictures below).
What I've tested and notes:
- Increased the padding to large values and changed the unit in order to see if this changes anything.
- Built the whole PDF. No difference to PDF preview.
- Web output works as expected (picture below).
- Found another thread where also problems with CSS styles in PDF output are described. However, without any real solution.
- It seems that PDF rendering in Flare does not take all CSS elements into account.
- Searched through the Flare documentation, but could not find any hints about (reduced) CSS in connection with PDF output.
My question:
Is this a bug in the PDF renderer? If not, is there any documentation about the limitations of CSS in PDF output?
Thank you for any hints
Mark
From my web-dev experience, your css only works in browsers because modern browsers are great at helping us coders out, but the PDF output is not so forgiving.
The short answer: <span>s do not respect padding styles by default, and that's showing in the PDF output. You can possibly fudge the look of it by adding non-breaking spaces before and after the text inside of the span, and changing the line-height to add top/bottom spacing.
The long-winded answer:
There are two main types of ways that elements 'display' (and several more not worth mentioning right now). They are: block-level elements and inline-elements. Structural elements such as <div>s are block-level by default, text-based elements like <span>, <b>, <i> etc. are inline by default. Inline elements DO NOT respect padding, width, height, and various other CSS styles that block-level elements do, but inline elements have benefits such as inherently being able to line-up horizontally with other inline elements (much like text characters you type-out) while block-level elements want to ALWAYS be on their own line and do not line-up horizontally by default. There is a hybrid display property that is literally "inline-block", but as far as I can tell this is not supported by PDF output.