#30030

You published as “response” returned HTTP content, which looks correct.

HTTP server also sends so-called “HTTP Header”, which should have “Content-type: application/pdf” entry.

Your JSP code also seems to be ok. So first I would suspect your web application has a config mapping “JSP -> plain/text”, and the configuration overrides “Content-type: application/pdf” set by PD4ML taglib.

#30039

Yes, I have established a font folder and TTF embedding.

Apr 19, 2017 9:51:48 AM com.mli.reports2pdf.Reports2PDF main
INFO: Report render complete.
Apr 19, 2017 9:51:48 AM com.mli.reports2pdf.Reports2PDF main
INFO: Report render begins.
Apr 19, 2017 9:51:48 AM com.mli.reports2pdf.Reports2PDF <init>
CONFIG: The optional pathOut argument was not supplied. The pathIn argument will be used.
Apr 19, 2017 9:51:48 AM com.mli.reports2pdf.Reports2PDF generatePDF
INFO: Generating PDF file for selected report. Report => Master_LabCorp_Requisition
Apr 19, 2017 9:51:49 AM com.mli.reports2pdf.Reports2PDF conditionalCaptureSTDOUTStop
FINE: version: PD4ML 3102 Pro
not yet in cache: file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/pd4fonts.properties
loading file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/pd4fonts.properties [3ms]
not yet in cache: file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMES.TTF
loading file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMES.TTF [2ms]
read ‘times new roman’ from file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMES.TTF
not yet in cache: file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMESBD.TTF
loading file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMESBD.TTF [3ms]
read ‘times new roman bold’ from file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/TIMESBD.TTF
not yet in cache: file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/courbd.ttf
loading file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/courbd.ttf [1ms]
read ‘courier new bold’ from file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/courbd.ttf
not yet in cache: file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/cour.ttf
loading file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/cour.ttf [1ms]
read ‘courier new’ from file:C:mliwsCoreEngineCoreEnginetrunkbrand_resourcesCommonFonts/cour.ttf
image not yet in cache: file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Clinical_Info.png
not yet in cache: file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Clinical_Info.png
loading file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Clinical_Info.png [1ms]
image size: 82785
image not yet in cache: file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Patient_Info.png
not yet in cache: file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Patient_Info.png
loading file:/C:/mli/wsCoreEngine/CoreEngine/trunk/LDB/patient-vmw/MEND_Requisition_Patient_Info.png [1ms]
image size: 412303
done in 380ms.

Apr 19, 2017 9:51:49 AM com.mli.reports2pdf.Reports2PDF main
INFO: Report render complete.

#30035

Oh, thank-you.

I don’t know where I got the idea that headers and footers had to begin with a <body> tag. I will enhance them to be a full HTML document and see if that fixes my problems. I will reply with my results.

#27147

Hi,

I have a requirement to create PDF in Chinese Japanese and Korean (CJK) Language also apart from other non-multi byte languages.

Our development server are mac/windows and production server could be any type of server like WIN/UNIX/LINUX/AIX or AWS/AZURE.

Currently I am need of free CJK fonts i can use as a JAR deployment file.

I tried following steps in TTF embededding pd4ml-html-css-pdf-tips-tricks-f7/ttf-embedding-t42.html with some converted NOTO ttf fonts, but I was not successful.

NOTO fonts from google are available in OTF. Is there any way i can use OTF fonts instead?

Or if i can get free CJK fonts in bundled JAR , so i can deoploy in my Web APP directly.

Thanks In Advance.

#30046

You may use free FontForge tool to convert OTF to TTF.

If you familiar with Python programming, you may also use the simple script
https://github.com/fonttools/fonttools/blob/master/Snippets/otf2ttf.py

#27146

We are working on a project for which we are considering PD4ML as a potential library to generate PDF’s… however as part of our trails we experienced that when we are providing 2MB image files and rendering 160 page PDF with entirely those images, we are getting a file of size not more than 3MB, I believe the image files are being compressed and put into PDF.. we want the high-definition images to be taken as is into PDF and the file should be generated.

Can you confirm if there is a setting to avoid compression..

#30040

PD4ML never downsamples images. It embeds images “as is” (JPEGs, some species of PNG, Fax TIFFs) or converts them to lossless internal PDF image format.

If the same image appears on multiple pages, resulting PDF will include only one instance of the image, referenced from multiple places.

#30033

> I don’t know where I got the idea that headers and footers had to begin with a

<body> tag.

PD4ML supports two ways to define headers/footers, and it can be confusing.

Other approach allows you to define headers/footers inline with <pd4ml:page.header>

tag. In this case a header or footer respects the main document stylesheets.

#30037

Can you please send to support pd4ml com an HTML and resulting PDF samples?

#30023

Can you please send a sample HTML (and accompanying CSS etc) to support pd4ml com?

#30041

Is there any size limit on the PDF generation? we are expecting the PDF’s to be around 200MB~

#30042

There is no hardcoded limitations. The data volume PD4ML can process is only limited by JVM heap size.

#30043

I am going to use .Net Library of PD4ML… just wanted to know if there is any chance that we might run into out of memory while generating the last size pdf’s with high definition images

#30044

That depends on where the document volume comes from.

If the document is bulky because of bulky images – it ok. PD4ML can temporarily unload static resources to cache and read them again at PDF writing phase.

If it is bulky because of a lot of HTML content: it can be problematic. HTML rendering assumes a lot of overhead – even a single standalone whitespace is represented in RAM as a number of Java objects (content itself, HTML attributes, CSS properties, layout info etc). In the case RAM requirements can be too high.

An experimenting with eval version can help a lot to estimate the max doc volume for your particular case.

Also do not forget a possibility to split the the doc to multiple parts (it it is possible for your doc structure), to convert them separately and to finally merge to a single PDF doc from just generated pieces.

#30045

Got it & Thankyou.

Is merging option available in Eval version? so that I can try it out?

[Author]

Posts