Our company is developing a WYSIWYG Tool for our client. The PDF Generation we are using now have some disadvantages, mostly problem with rendering letter-spacing. For that reason we are looking for the new solution. We have found Prince and it looks really interesting. However, before buying the license we want to be sure that this component will work properly in any cases. For that reason we perform some test, and we can see that Prince is working really good.


However, after first tests, we have found two problem with rendering font styles and text line-height. I prepared a simple examples to show you where is the problem. The first picture shows a HTML view with four text fields. Below each field I put a blue line, to mark the end of the paragraph.


The second picture is the PDF preview genereted by Prince.



1) The first problem is with font style. Where there are nested tags, Prince has problem with reading text styles. You can see it in the text field from the 1 example – HTML:

<div contenteditable="true" style="text-align: left; letter-spacing: 0pt;">
     <font style="color: red;">
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam turpis quam, pharetra in congue in, adipiscing eget sem. In ac volutpat enim.
          <div style="text-align: right; color: blue">
               Pellentesque nisl orci, ultricies sit amet libero at, ultrices mattis nisl. Etiam accumsan dui in ligula condimentum dictum.
          </div>
          Morbi ut luctus nunc. Vestibulum non nibh a turpis commodo fringilla id ut lorem.
     </font>
</div>

Apparently when there is a <div> tag inside a <font> tag, Prince has problem with reading a color of the text that is after <div>, but still inside <font> with definded color. In this case text gets color of its parent tag. The same problem you can see in the third text field, where Prince doesn’t read color and font-face.


2) The second problem is with line-height property. The line-height value is interpreted correctly only in very simple situation, like in the second text field of 2 example – HTML:

<div contenteditable="false" style="line-height: 16pt; text-align: left; letter-spacing: 0pt;">
     <font style="color: rgb(78, 102, 150);">
          <font style="color: rgb(208, 65, 118);"><b>Correct line-height</b></font>
          <br>
          Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam turpis quam, pharetra in congue in, adipiscing eget sem. In ac volutpat enim. Pellentesque nisl orci.
     </font>
</div>

When I added more styling, the line-height wasn’t good. I think that the problem occurs when I add a <font> tag with font-face specified or where there is a <div> tag inside <font>. There also may be more situations problematic for line-height, but I need more time for testing. The HTML of the first text field from 2 example is:

<div contenteditable="true" tabindex="0" style="line-height: 30pt; text-align: left; letter-spacing: 0pt;">
     <font style="font-size: 12pt;">
          <font face="Mias_Scribblings_BTCE_SG">
               <font style="color: rgb(208, 65, 118);">Wrong line-height<br></font>
               Lorem ipsum dolor sit amet, consectetur adipiscing elit.
               <font color="ec7205" style="color: rgb(236, 114, 5);">Mauris blandit, quam vel viverra tincidunt, felis risus pharetra mauris</font>
               , id iaculis ligula ligula a enim. Aenean vel velit.
          </font>
     </font>
</div>

3) The 3 example shows both problems – HTML:

<div contenteditable="true" style="line-height: 30pt; text-align: left; letter-spacing: 0pt;">
     <font style="font-size: 14pt;">
          <font face="PetitaLight_BTCE_SG" style="color: rgb(208, 65, 118);">
               Lorem ipsum dolor sit amet, consectetur adipiscing elit.
               <div class="" style="text-align: right;">
                    <font face="Underwood_Champion_BTCE_SG">Nam turpis quam, pharetra in congue in, adipiscing eget sem.</font>
               </div>
               In ac volutpat enim. Pellentesque nisl orci, ultricies sit amet.
          </font>
     </font>
</div>

This properties are very important for our WYSIWYG Tool, and if they are not properly rendered in PDF we cannot use Prince. Therefore, could you please tell us if you can fix this bugs in the nearest future? I hope it’s possible, because we really like your component.

1. html_view.png‎ 84.6 kB ‎
   HTML view
2. prince_view.png‎ 129.1 kB ‎
   Prince view

At least in the first example, I can get it to work as you want by redefining <font> as a block element:

font { display: block; }

Odd things tend to happen in HTML when you put block elements inside inline elements

Dave

Thanks for reply. I will check if we can use "display: block" for <font> elements.

Do you have any ideas about problem with line-height property?

I checked your solution and after setting "display: block" on the <font> tag text styles are correctly interpreted. Unfortunately we cannot use this solution, because we give user full control over the editable text, what means that after some modifications the same <font> tag can become linear element. Therefore, could you propose us a different solution?

I don't think the old <font> tag can be implemented in CSS, and so it probably cannot be correctly implemented in Prince.

<font> was deprecated fifteen years ago. You might want to find an editor component that uses better markup. We've had good luck with CK Editor.