• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

SOLVED : DomPDF multiple issues ?

Status
Not open for further replies.

sunnyjey

Active Member
Yesterday, I have updated the Github with new mPDF Library. I found multiple problems:

1. CSS for @page and {body} are not working.

If I add background-color: red !important for @page, the color turns red, but it is limited to the first Page of PDF !

'Margins' in @page / body are not working, despite of adding !important tag.

2. inline css are not working.

3. Page numbering {PAGENO} are not working !

4. If I enabled PDF Attachment in EMail form plugin, it do not grab CSS at all (http://fabrikar.com/forums/index.php?threads/email-form-plugin-attach-as-pdf.48232/)

5. If I change mpdf to dompdf in the Fabrik Options, I guess it still loads mpdf library even after clearing the browser cache.

6. PDF download link opens into the Browser instead of downloading into the local computer

Can someone confirms these issues on their testing server ?
 
Just tried PDF Output after a Github Update yesterday and was shocked by the result. (My last Update was more than 2 weeks ago)
I did NOT change PDF output to MPDF so expected to see no change at all but what shows up now:
  • No UTF-8 characters in Labels and Data. They worked with arial before. Tried 'dejavu sans' but got no improvement. I even don't see them in browser when PDF debug is activated. Yes, the form still shows them.
  • Page numbering is not working.
  • Multi-column output is now single column with very narrow width - could be the Margins issue above.
The PDF engine is displayed as mPDF 7.0.2 although DOMPDF is set in config. Toggled back and forth but no change shows up. I doubt that this is a browser issue.

What still works for me is the PDF Download/Open Link, which will open it in my PDF program.

How could we revert back to DOMPDF?
 
@fstorch : Glad to know that these issues are not isolated to my Server.

The PDF engine switch mPDF/DomPDF in backend is working. Thanks to the Hugh.

I have selected DOMPDF, but it shows overlapped text. Tried all possible CSS tricks.
OnPaste.20180326-120640.png

I really don't know, this is because of new DomPDF library or something else. But it all started, since I upgrade Fabrik through GitHUB.

mPDF has above-mentioned problems (@page/body CSS; Page Numbering; PDF opening in the browser).

Is there anyway, I can set or alter the default margins of Page in Fabrik mPDF library OR revert back to the old DomPDF version library ?
 
@cheesegrits : Thanks Hugh, for the quick fix. Toggling engines works fine again.

But I also have to confirm @sunnyjey's findings. Lines totally overlap despite any height or line-height used.
I guess that's one of the problems that the latest version of DOMPDF introduced?

And I also don't get UTF-8 chars with dompdf. Switched to 'dejavu sans' and verified that it is installed in
/libraries/fabrik/vendor/dompdf/dompdf/lib/fonts/

The good news is, that mPDF does show UTF-8 chars with 'dejavu sans' again.
But it doesn't generate 2 column output (very important) and doesn't do page numbering (less important for me).
Looks like the 2-column ouptut is some kind of width problem. When I activate debug PDF, the output is 2-colums until the browser window width is reduced.
And PDF-XChange found some problems in it (one ore more XREF-Datastreams not found)

So this seems to be a catch-22 now. No pdf engine is working acceptable currently.
 
Lines totally overlap despite any height or line-height used.
I guess that's one of the problems that the latest version of DOMPDF introduced?

So this seems to be a catch-22 now. No pdf engine is working acceptable currently.

Yup and yup.

I added mpdf to provide the choice, in the hopes that where one fails, the other will work.

I'm still trying to work out that line overlap thing in DOMPDF. The problem being, I can't get it to do that on any of my test server, but I'm seeing it a lot on other people's systems. I don't think it's CSS related, I think it may be font metric related. But until I can somehow replicate the problem here where I can properly debug, I'm flailing around in the dark.

Some days I'm tempted to just ditch PDF entirely, it's been the bane of my existence forever. There is no "one size fits all" solution, all the HTML to PDF converters out there suffer from one problem or another. But I know Fabrik users rely on having it.

One kind of radically different solution I've been looking at is Cloud Convert, https://cloudconvert.com, which actually does a much better job of it than any of the PHP libraries I've tested. Obviously a lot trickier to use, and isn't suitable for all use cases, but for background creation, with notification and a download link when the doc is ready, it's viable.

-- hugh
 
I?m somewhat confident that I can make mPDF work acceptable while the overlay problem and the sudden lack of utf-8 chars seem like unsolvable problems with dompdf.
I think you may be right, that it could be a font issue.
 
Strange
I just updated to the latest Git and domPDF is working fine with UTF8-characters and custom colors (list view).
I copied bootstrap to bootstrapPDF, created custom_css.php with
* {font-family:'dejavu sans'!important;color:green;}
td.fabrik_element {color:blue}
and get
upload_2018-3-26_23-31-26.png

mPDF is also acceptable (ignoring the green color, but UTF8)
upload_2018-3-26_23-34-55.png

mPDF is opening the PDF in the browser in the same tab, should be a new tab or download...
 
@fstorch : Have you managed to make @page or {body} margin working in mPDF? If yes, can you share your method ?

@troester : As I said earlier, CSS (particularly margin which is crucial for page setup) for @page are not working for detail view. Also page numbering are not working.

I know Hugh is working hard to resolve this issue. For my project, PDF generation is one of the most important factor. I am badly hit due to this bug and almost all my operations are halted since the upgrade. Is there anyway, I can set or alter the default margins of Page in Fabrik mPDF library OR revert back to the old DomPDF version library ?
 
@sunnyjey : Didn't start to make pagenumbers (and probably pagebreaks) work with mPDF. Still need to fiddle with the 2-column/float output. {body} margin is different to dompdf but actually in my case usable.

@troester : with mPDF UTF-8 is working just fine: upload_2018-3-27_8-33-26.png
When switching to dompdf I get:
upload_2018-3-27_8-32-46.png

What's really strange is, that a testsite (same server), which I didn't github for long (Feb 2018?), lost umlauts with dompdf as well: upload_2018-3-27_8-36-37.png upload_2018-3-27_8-41-57.png upload_2018-3-27_8-42-21.png
 
@troester Thank you. But, it seems you have misinterpreted. Maybe, I have not provided enough details.

Right now DomPDF is completely unusable, as PDF generated (from detail view) shows Overlap TEXT (check attached screenshot in my earlier post). Strangely, the Header and Footers displays correct CSS styling and text. Since the DomPDF is not correctly rendering readable TEXT, we (I & @fstorch) are considering the mPDF as an alternative till the time Hugh fix this DomPDF bug.

mPDF renders the TEXT correctly. But, it do not grabs CSS (particularly margin) for @page and {body}. The other issues are Page Numbering and Opening URL in the browser. It seems @fstorch made a successful attempt in Float, but not about @page margins.

@fstorch :
What's really strange is, that a testsite (same server), which I didn't github for long (Feb 2018?), lost umlauts with dompdf as well:
Yes, this happened with me too. When I discovered the Overlapping TEXT issue after Fabrik GitHub upgrade, I re-stored my entire website from my existing 24 hours Akeeba Backup, but strangely found same error.

@cheesegrits : I have found the exact issue like ours on domPDF GitHUB forum (I believe you have already browsed these pages & by this time must be looking at Cache file). The screenshot attached to the following Github post is similar to us.
  1. https://github.com/dompdf/dompdf/issues/1120
  2. https://github.com/dompdf/dompdf/issues/1422
The issue looks like due to some Font Metric, as Hugh, has already pointed.

Perhaps the font metrics files are not being read correctly. You might try installing a fresh copy of dompdf, "resetting" your font directory, or fixing the paths in the dompdf_font_family_cache.php file. Check your dompdf_font_family_cache.php file and make sure any paths in that file are accurate.
 
OK, DOMPDF should be fixed.

Dumb mistake on my part. I accidentally committed some files I was playing around with in DOMPDF a few months ago, where I was adding the 'icomoon' font so PDF's of some icons in the default J! bootstrap set would render. And the font paths in that file used \ instead of /. So everything worked fine on my test server, which is Windows, but anyone with Linux servers who uploaded from github (since 3.8.1) would have had this problem.

I've fixed the paths in github:

https://github.com/Fabrik/fabrik/commit/be69395a0c2af1396d8e46cda385345b20473e52

... although all you have to do to get it working again is just delete that file:

libraries/fabrik/vendor/dompdf/dompdf/lib/fonts/dompdf_font_family_cache.php

... and just leave dompdf_font_family_cache.dist.php, which is the out-of-box fonts shipped with DOMPDF.

I'll probably remove that extra cache, and the additional font files I added. Left it for now while I play around with some other fonts.

-- hugh
 
Status
Not open for further replies.
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top