#36789

Hi Mauro,
we’ve converted your question to a helpdesk request. You’ll receive a notification soon.

#36783

> I don’t think it is a path problem of the pd4ml.jar either, because the library is found, otherwise the whole PDF printing would not work.

The problem is not in finding of pd4ml.jar
The libraries from common lib/ and WEB-INF/lib/ are loaded by different classloaders. Libraries loaded from common lib/ may not see local web application resources.

#36731

It looks like an issue of web application configuration: for some reason the servlet resource provider does not recognize /servlet/ prefix as a name of local web application.

Did you place the v4 pd4ml*.jar in WEB-INF/lib or is it in the common lib/ directory? Since the new taglib JSP classes are in pd4ml*.jar, the location of the JAR (which determines which classloader is used) can be relevant.

For a smoother transition of JSPs from PD4ML v3 to v4, we recommend that you leave the JSPs as they are and store pd4ml_tl.jar from v3 in WEB-INF/lib. Generally, taglib v3 works well with PD4ML v4.

#36702

Hi! It should not be non-breakable. It looks like an undesired side effect of our tuning of CJK line break logic. We’ll investigate the issue and let you know

#36663

Hmm… It is not the feature can be easily implemented. It cannot take the original CSS styles (the used in source HTML/CSS sizes/dimensions change itself depending on conversion scale factor, see https://pd4ml.com/support-topics/pd4ml-v4-programmers-manual/#customizing) and there is no possibility to export the initial original stylesheet rules/properties, aligned depending on conversion params.

It seems like the only possible way is to go through all the HTML elements and find repeating styles (after the style and scaling is applied); if there are matches, to synthesize a style sheet from them with arbitrary class names.

I’ve added the feature request for future releases. Not sure if we can address it within the next couple of months

#36654

Currently all document styles are already applied to RTF elements/content blocks. And you would like to see HTML’s CSS converted to an editable RTF document stylesheet, and if you edit it in MS Word it will impact all relevant RTF content blocks. Right? Please correct if I am wrong

Or you simply cannot get needed style applied to particular RTF content, while for PDF output it works

#36651

In most cases, it retains such styles. However, some of the styles simply don’t have RTF equivalents; some require tricky solutions like defining paragraph borders. The RTF format does not directly support paragraph borders, so if it is requested, PD4ML will implicitly convert the paragraph to a table cell (which supports borders).

#36649

Hello! As far as I remember, this is only an RTF problem. For PDF output, you can specify empty anchors, but RTF viewers always require that the anchor be assigned to an existing object or piece of content. Creating dummy content (such as whitespace) for empty anchors has an undesirable impact on the resulting document layout

#36618

The pageNumberTemplate and pageNumberAlignment attributes in the code

<pd4tl:header
titleTemplate=”$[title]”
titleAlignment=”left”
pageNumberTemplate=”Seite $[page] / $[total]”
pageNumberAlignment=”right”
/>

are supported for backward compatibility with text-only headers/footers of PD4ML v3. They are converted into HTML table with the simple code:

style += "font-size: " + fontSize + "px; ";
tpl = "<table width=100% border=0 style=\"" + style + "\">\n<tr>\n<td width=33% style=\"" + style + "\">" + left + 
	"</td><td align=center width=33% style=\"" + style + "\">" + center + "</td><td width=34% align=right style=\"" + style + "\">" + right + "</td>\n</tr>\n</table>";  

and obviously affected by TD style

The best approach would be to use your header markup, not relying on v3 legacy and the auto-generated three column table

<pd4ml:page.header>
... HTML ... ”$[title]” ... HTML ... Seite $[page] / $[total] ...
</pd4ml:page.header> 

But if you need to provide a compatibility to older HTML/JSP templates, you can add the explicit style: pd4ml-page-header TD {text-align: right;}

And of course, we’ll try to resolve the issue with an ignoring of pageNumberAlignment=”right”

#36617

The implementation of the feature only outwardly looks simple.

In order to implement the complex selectors, the CSS runtime is implemented as a specialized state machine: an appearance of a new HTML element in the parsing stream pushes the event to all selectors (they may either refuse the event or to change the entire runtime state). A closing HTML tag pops to previous state. At any document parsing point we can request the runtime to generate a list of properties matches the current CSS runtime state. Actually it is done for every parsed HTML element and it defines the final document style.

The single-pass approach works well in most cases, but :last-child / :last-of-type creates problems for it because it cannot look ahead and determine if a particular tag is the last one or not. Keep in mind that :last-child / :last-of-type can be combined with other conditions such as P[attr=value]:last-child, so a quick HTML scan by tag name is not enough. Also, the actual “last child” could be at the end of a huge HTML document, megabytes away from the current parse point.

All of our previous approaches to implementing :last-child / :last-of-type functions resulted in a significant performance degradation, drastic for large HTML and CSS documents. We’ve already tried to fork HTML and CSS parsers to check in idle run whether a particular element is the last one in terms of selector conditions; we tried to clone the CSS state with last=true and last=false and then remove the misguessed state. Both approaches did not match our acceptance criteria from performance perspective.

We have not exhausted new ideas on how to implement the feature yet, but, I’m afraid, we will be able to return to them only closer to September

#36555

I’m afraid that :last-child and :last-of-type won’t be supported without a complete refactoring of the CSS runtime.

Support requires either an additional parsing pass of entire HTML document, or non-trivial look-ahead parsing logic (in extreme cases, it takes even more time/resources than a second parsing pass).

All our attempts to implement this feature resulted in significant performance degradation even in simple cases where this feature was not used. We have decided to temporarily omit the feature

#36409

Did you enable pd4ml.adjustHtmlWidth() mode? In this case, it scales the content down to fit the target page (in its initial portrait format). So after turning the page into landscape, its “extended” right side will always be blank.

If you enabled pd4ml.adjustHtmlWidth() mode, first try to switch it off.

The samples from https://old.pd4ml.com/cookbook/pdf_dynamic_format_change.htm seem to implement exactly what you needed

#36392

v4.0.16, which fixes this issue, is scheduled for release on Monday, May 22, 2023.

#36365

In order to render the glyphs you need to make sure the glyphs are present in used TTF font.

As it follows from your Java code snippet, you did not enable TTF embedding at all, so it uses built-in core fonts, support Latin-1 charset only and do not implement the glyphs.

The attached PDF is generated with the TTF embedding enabled. PD4ML took the glyphs from MS Gothic TTF font

See https://pd4ml.com/pdf-fonts/ for TTF embedding hints

Attachments:

You must be logged in to view attached files.

#36354

Hi Paulam,

try <pd4ml:page.break pageFormat=”reset”/>

[Author]

Posts