#35875

The issue is obviously depends on test.htm content. Can you please share it with us?

#35842

I’m afraid even if we merge the fix into the v4.0.13 branch, the new build date will not be covered by the license code that comes with your product.
If you are not a PD4ML licensee, it is better you request a patch (updated PD4ML jar + license code) from the vendor.

#35841

I’m afraid even if we merge the fix into the v4.0.13 branch, the new build date will not be covered by the license code that comes with your product.
If you are not a PD4ML licensee, it is better you request a patch (updated PD4ML jar + license code) from the vendor.

#35839

Hi Bharat,

the page layout consists of absolute positioned blocks only, which caused the document height calculation logic to make incorrect assumptions, also impacting footer placements.

The currently available v4.0.15fx2 snapshot build already resolves the issue. Please give it a try.

#35831

We are investigating the issue right now. Sorry it takes that long

#35826

https://pd4ml.com/pd4ml-v3-to-v4-migration-guide/#basics-2

#35825

In the case you simply need to place the pd4ml.lic file to the Web application working dir.

See for more info:

PD4ML v3 to v4 Migration Guide

#35823

Hmm… PD4ML .NET only available as v3, which requires no activation code or pd4ml.lic file.
Can it be you call the Java lib from the .NET Web application?

#35810

We’ll add you to the help desk ticket participants so that you can track the status and get the possible workaround ideas. Unfortunately I cannot do it right now by technical reasons. I’ll update you with the status on Monday.

#35807

Thank you! Most probably an upgrade from 4.0.13 to 4.0.15fx2 helps with the huge margins and the right edge content cut.
The correct document height calculation needs to be solved on our side.

#35804

> Do I need to mention the style in the html source to display the entire content?
Try the style as an experiment.
Also try to define java.awt.Insets(0,0,0,0) to see if it impacts the resulting page margins.

From our side it is difficult to guess where l:142.0, t:142.0, r:142.0, b:142.0 margins may come from.

#35802

I can generate the entire content only if I explicitly define the document height:
body { height: 150cm; }

Your HTML layout consists of absolutely positioned blocks. Such layout for some reason makes actual document height computation incorrect. I’ve opened the internal ticket to fix the issue with the top priority. But the above style can be used as a temporal workaround.

> Moreover we are not setting any page margins, all we are doing is setting insets.
In PD4ML v3 we called the “page margins” as “page insets”. But they mean the same in the context.

#35799

Hi! The problem comes from strangely defined PDF margins in v4 version.

Here is the API calls dump of v3:

% PD4ML version: 3100.PRPC.1 Pro
% JDK version: 1.8.0_342
% OS version: Linux 3.10.0-1160.76.1.el7.x86_64
% File encoding: UTF-8
% insets: java.awt.Insets[top=85,left=71,bottom=85,right=71]
% size: java.awt.Dimension[width=595,height=842]
% protectPhysicalUnitDimensions
% interpolate: true
% footer: 
% pn tpl lng: 19
% pn alg: 2
% init pn: 1
% skp: 0
% fn sz: 11
% hgh: 20

As you can see the margins (aka insets) are set to moderate values in typographic points: [top=85,left=71,bottom=85,right=71], and the page size matches A4: [width=595,height=842]

When you call v4, the settings differ:

%  PD4ML DIAGS
%  
%  Version: 4.0.13
%  JDK version: 1.8.0_352
%  OS version: Linux 3.10.0-1160.80.1.el7.x86_64
%  file encoding: UTF-8
%  supplied license 'java:pd4ml.lic...': v=true, i=true, p=true, pa=true, pb=true, pr=true, rt=true
%  setPageMargins: [null] l:142.0, t:142.0, r:142.0, b:142.0
%  setPageMargins: [null] l:141.75, t:141.75, r:141.75, b:141.75
%  setPageSize: null,595x842
%  % protectPhysicalUnitDimensions
%  injectHtml*: 469 true
%  ttf: java:/defaultfonts
%  setPageMargins: [null] l:142.0, t:142.0, r:142.0, b:142.0
%  userspace=640
%  setPageSize: null,440x623

The page margin are suspiciously huge: l:142.0, t:142.0, r:142.0, b:142.0
And the page size for some reason degraded to 440×623 from initial 595×842(A4).

I would recommend to start the troubleshooting with a switch from Version: 4.0.13 to 4.0.15fx2 – obviously you do not use PD4ML v4 API directly, but PD4ML v3 -> v4 API wrapper classes. We fixed few issues with the default page settings in the meantime.

And please check your code to determine where 142pt margins come from.

The attached is PDF output of the current v4 build.

Attachments:

You must be logged in to view attached files.

#35790

Hi! Could you please also share the source HTML doc with us?

#35785

The org.zefer.pd4ml classes in v4 are to support v4 JAR as a drop-in replacement for v3. The classes translate old API calls to the new ones where it is possible.

PD4ML_ABSOLUTE_ADDRESS_SPACE = document behavior tried to simulate pagination logic of HTML printing in older Web browsers. As far as I know, modern browsers does not break pages that way anymore. So we did not try to reimplement the feature in v4 (yet).

[Author]

Posts