Pdfmake: Option for paid support

Created on 1 Dec 2017 · 4Comments · Source: bpampuch/pdfmake

I am no sure if this is the right place to ask this question, but as we start using this awesome library into the application, management is asking question about support behind this product line. A recent question asked was what is the date for 0.2.0 availability? How can we get support for international languages?

So question to the team, is there an option to get paid support?

Source

skillguru

Most helpful comment

Roboto font has a small file size because it contains only some code page of languages (chinese not supported). All fonts with chinese code page are big file size, because they contain many characters. File vfs_fonts.js is larger than the original font file because everything is in base64 (it require javascript).

Webworker can be used as a partial solution (works in different browser thread) with all advantages and disadvantages, but large file still needs to be downloaded. See example (from issue https://github.com/bpampuch/pdfmake/issues/38).

Ideas for how to improve this are welcome, but still the font files must be available in browser, so downloading will still occur.

liborm85 on 5 Dec 2017

👍2

All 4 comments

Support is provided only on GitHub via issues in English.
Paid support is not available.

Version 0.2 - Currently I do not have any plans to release version 0.2. New features and bugfixies will be continuously added to 0.1.x versions. Is there any feature missing is actual released version, that you need?

liborm85 on 2 Dec 2017

We are having troubles with size of the file when printing Chinese characters. We are using fireflysung.ttf and this is packaged with the vfs_fonts.js file and delivered to client browser along with pdfmake library. The challenge is that fireflysung.ttf size is about 15 MB, so the vfs_fonts.js became 20MB. The original file size with Roboto font only is 933 KB.
Now user will have to wait for the vfs_fonts.js file download before the customer starts exporting. We can defer this download at the end of the page load but still it is a pretty big size.
Is there a better way to support multiple languages?

skillguru on 4 Dec 2017

Unless PDFMake can somehow use the font data from the user's system fonts (which I highly doubt, and wouldn't give you any control over the text appearance) then there is nothing that can be done to avoid this issue. I've been dealing with this exact situation for years, first in Flash, then with SiFR, Cufon, and now web fonts. CJK character sets are just fundamentally too large to use in any case where you have to include the actual character data in any data transmission. Providing reasonable advance warning to the user of the large download, and providing a download status/progress bar, is your best bet. If the user really wants the content in your PDF, then 20mb probably won't stop them unless they're on a mobile device.

G-zipping on the server would help if that's not already being done -- vfs_fonts.js should gzip pretty well.

Otherwise the only thing I can think of is to generate the PDFs on the server instead of the browser, or maybe generate the text portions as images on the server and include them in the PDF. Believe it or not that'll be faster for the user than transmitting the actual font files unless you're making PDFs with more than 10 or 15 pages.