#30197

As a feature request it would be nice if pd4ml would fallback to a own font that contains all symbols instead off printing a questionmark. If i’m not mistaken it’s what the browser are already doing.

The browsers are native application, which have access to all available fonts. Java as a rule has only “proxied” access to the fonts via java.awt.Font object. The object has a lot of useful features, but it does not provide an access to the TTF file itself (we need a physical access to the file tp parse it and partially embed to PDF) – that is why that confusing pd4fonts.properties indexing is needed.

Well – Java can “guess” that the TTFs are in c:/windows/fonts, but there are a lot of fonts there and parsing of all of them to find the one, which has a desired glyph is a resource and time consuming task.

A native application has all the needed info easily available and a font substitution tables are tuned for the platform and available fonts. In Java case we need to come up with a general platform independent solution…

Regarding the original issue: go through the list of available fonts on Win server and check which one contains the glyph – I did so with the standard Character Map application. There are some “glyph-reference” pages in the Internet – probably they refer to popular TTFs, that implement the glyph. After the font is found, explicitly refer it from your HTML/CSS (and make sure it is mapped in pd4fonts.properties). We’ll look for the font also on our side by an opportunity.

#30153

@PD4ML wrote:

Could you also publish initialization of isr and fos (it is not clear what is behind them) as well as full exception stack trace?

Agree please share more details!
https://crbtech.in/online-java-training-course

#30205

Hello,

We have tried the proposed workaround with position: relative; top: , unfortunately it did not work. We have tried to modify values of top manually so they would result in a good result in PDF, but did not find any rule or algorithm or coefficients that could be generally used to adjust the vertical alignment in PDF correctly.
It would be great if you could help us solve this problem, as in the current state exported document is almost not usable.
I am attaching the link to a sample HTML document (original with vertical-align) that we are trying to export:
https://drive.google.com/file/d/18EWWqF7Ij_t-qQ6bf8VOY9ESTMZrQumO/view?usp=sharing. I can also provide documents with vertical-align changed to position: relative; top: … if that could help.

Thanks in advance,
Elena

#30202

We’ll check what could be done. However a solution is going to be implemented in v3.10.x and v4

#30203

Thanks a lot,
Elena

#30189

That’s great. The ordering is correct now.
Unfortunately, soft hypen (shy) are always rendered, not only on line breaks.
Is there an overview of supported feature for the 4.0 release?

#30204

Hi,

If there will be any update or new information, please write here, I keep checking this topic 🙂

Elena

#27218

Hello everybody

I use PD4ML 3.8.5fx6 to convert html to pdf and have the problem that depending on font size within the paragraph of the footer the footer is not shown. Instead there seems to be a very large margin at the bottom when pdf is viewed in LibreOffice Draw. (Of course I do not use that as my normal pdf viewer. In Adobe Reader the footer is missing as well.)
With a small and large font size it works, but not with a medium one.
The font size (and the timestamp of course) is the only thing that differs between the htmls to be converted.

Do you have an idea what might be the reason?

Thank you!

#30215

By the way, I tested it with font sizes from 3pt to 12pt. Just the 7pt does not work.

#30214

Hi! The issue should be resolved in actual v3.10.x versions. Please give the most recent v3 version a try or switch to v4.

#27219

The current results looks like the follwoing values are used for pixel / dot / inch conversion:
72 DPI / 97 PPI

should not the follwowing values usesd?:
72 DPI / 96 PPI

It looks like a internal rounding bug. INT to float or something like that.

Converted px values looks like 97ppi is used…

STYLE:
<br /> <style type="text/css"><br /> body {<br /> font-family: Arial;<br /> font-size: 9pt;<br /> }<br /> <br /> .page {<br /> margin: 0 auto;<br /> width: 21cm;<br /> }<br /> <br /> .page-body {<br /> margin-left: 10mm;<br /> margin-right: 10mm;<br /> }<br /> <br /> .square {<br /> background-color: black;<br /> color: white;<br /> margin-bottom: 1mm;<br /> text-align: center;<br /> padding: .5em;<br /> }<br /> </style><br />

HTML:
<br /> <div class="page"><br /> <div class="page-body"><br /> <h1>Hello World</h1><br /> <br /> <div class="square" style="height:1in;width:1in;">width 1in</div><br /> <div class="square" style="width:2.54cm;">width 2.54cm</div><br /> <div class="square" style="width:72pt;">width 72pt</div><br /> <div class="square" style="width:96px;">width 96px</div><br /> <hr><br /> <br /> <div class="square" style="width:2in;">width 2in</div><br /> <div class="square" style="width:5.08cm;">width 5.08cm</div><br /> <div class="square" style="width:144pt;">width 144pt</div><br /> <div class="square" style="width:192px;">width 192px</div><br /> <hr><br /> <br /> <div class="square" style="width:4in;">width 4in</div><br /> <div class="square" style="width:10.16cm;">width 10.16cm</div><br /> <div class="square" style="width:288pt;">width 288pt</div><br /> <div class="square" style="width:384px;">width 384px</div><br /> </div><br /> </div>

#30216

By default PD4ML convert all physical units to screen pixels using 72ppi, after that the entire document content is scaled depending on htmlWidth value (width of virtual HTML renderer frame) and on the chosen target paper format width: htmlWidth is mapped to pageWidth, so the actual scale factor varies and is not bound to 72 or 96 ppi.

If you prefer to work with physical units, trigger
pd4ml.protectPhysicalUnitDimensions() – in the case the elements should appear on paper in the originally desired size.

#30217

Please look at the code:

<div class="square" style="height:1in;width:1in;">width 1in</div><br /> <div class="square" style="width:2.54cm;">width 2.54cm</div><br /> <div class="square" style="width:72pt;">width 72pt</div><br /> <div class="square" style="width:96px;">width 96px</div><br />

All bars should have the same width but the 96px bar is smaller… a 97px matches so i think the internal factor is wrong or rounded to much or something like that.
A global scale should not do something on the relative size of the elements to each other 1inch = 2.54 cm; 1inch = 72 pt; 1inch = 96px <- and it looks like this is actually 1inch = 97px The match of real paper inch don't matter here.

#27323

@PD4ML wrote:

Please try to substitute your fonts jar with this one:
http://pd4ml.com/i/allfonts.zip (34 MB!)

unpack it and place fonts.jar to the classpath of your application (or to lib/ folder if any).
Refer the fonts this way:
pd4ml.useTTF(“java:fonts”, true);

And make sure the HTML has a correct meta charset directive.

Does it solve the problem?

No it does not solve the problem

#27322

No it does not solve the problem

If you are interested to get a support from us, please provide more details about the issue you faced with. There is a variety of reasons why some fonts are not rendered correctly.

[Author]

Posts