Following bug-report related to mPDF v5.5

1. <PRE>...</PRE> doesn’t works properly.
   
   
   1. It doesn’t apply CSS-style to <pre> inside <ul>/<ol>.
   2. If <pre> element appears inside the list (inside <li></li>), all the paragraphs will be broken. For some reason mPDF adds an additional line break after each paragraph and after each table. Also, for some reason, even table which used in PDF footer (as HTML footer) will have additional line break, destroying page margins.
   3. It adds odd top padding to each <pre> in normal content (outside of <ul>/<ol>).
       
   To reproduce the bug — just add some pre with custom background:
   

   Hello World
   

   Here is an ugly workaround which I have to use, to fix this bug outside of mPDF:
   

   function pre_to_div($html) {
     return preg_replace('/<pre>((.|\s)*?)<\/pre>/i', '<div class="ex_pre">$1</div>', $html);
   }
   $html_for_mpdf = pre_to_div($html_for_mpdf);
   
   .ex_pre class described as
   div .ex_pre,
   pre {
    font-family: Courier New;
    padding:4px;
    width:99%;
    overflow:auto;
    background:#EFEFEF;
    border:1px dotted #CCC;
   }
   

2. Oh shit! Even after the workaround above, it appears that mPDF doesn’t applies the CSS-styles for <div>’s insde the lists... And <div> is no more blocking HTML-element :( But at least it doesn’t breaks styles after the list...
   
   Well, another workaround: we can add <br /> after each <div> inside the list. Plus we can convert \n-style linebreaks to <br />’s inside the pre (which become <div>’s) now:

   function unescape_quotes($s) {
     return str_replace('\"', '"', $s);
   }
   
   function _mpdf_list_workaround_li($html) {
     return preg_replace('/<div([^>]*?)>((.|\s)*?)<\/div>/ie', "'<div'.unescape_quotes('$1').'>'.nl2br(unescape_quotes('$2')).'</div><br />'", $html);
   }
   
   function mpdf_list_workarounds($html) {
     return
       /* add <br /> after each <div> inside <li>'s
        This code sucks, since it will also unable to process blocks after nested lists, like
          <ol>
            <li><!-- this will be processed -->
              <ol>
                <li><!-- this will be processed too --></li>
              </ol>
              <!-- this will NOT be processed! -->
            </li>
          </ol>
       */
       preg_replace('/<li([^>]*?)>((.|\s)*?)<\/li>/ie', "'<li'.unescape_quotes('$1').'>'._mpdf_list_workaround_li(unescape_quotes('$2')).'</li>'",
       // replace all <PRE> with <DIV>'s
       preg_replace('/<pre>((.|\s)*?)<\/pre>/i', '<div class="ex_pre">$1</div>', $html));
   }
   
   

3. Damn... one more bug with CSS-processing... You probably noticed red outlined div above in example of CSS, which describes «.ex_pre» class. It’s because mPDF don’t understand styles described as «tag .class». So, unfortunately we have to declare .ex_pre class for ALL tags, not exclusively div’s :(
    
4. And yet more bugs with lists... mPDF displays all the text after «inner» <ol> as next list item.
   
   For example,
     <ol>
         <li>First level item 1
             <ol>
                <li>Subitem 1</li>
                <li>Subitem 2</li>
             </ol>
              This text will be displayed as separate list item #2, and text in real 2nd item will be displayed as 3rd list item.
          </li>
         <li>First level item 2</li>
     </ol>
   
   (The workaround above which replaces <pre>'s with <div>'s also contains this buglike feature)