#33990

PD4ML wrote:

I am not sure if a nesting of section tags is semantically correct: usually a document divided to sections, sections to articles. However from technical perspective a section should be just as a regular div has no restrictions for a nesting. (And now the section tag is treated rather as a paragraph, which is not correct)

Understand, but this is a content we receive from a client, and I’m afraid we cannot influence it anyhow.

PD4ML wrote:

We’ll align the issue asap.

Thank you!

PD4ML wrote:

BTW: do you still receive no Helpdesk notifications? Yesterday it looked like we fixed a configuration issue.

Yes, I received a notification today, thanks!

#33991

Currently, the PdfDocumentBase class allows you to change well-known document meta data, like .setTitle() to set the title, .setAuthor() to set the author, etc.
But there is no way to set/add custom meta data to existing PDF documents.
Could this be added?

#33992

The similar methods are available from com.pd4ml.PD4ML (v4 API) directly. There are setAuthorName(), setDocumentTitle() and addMetadata() for arbitrary meta data settings.

https://pd4ml.tech/javadoc/com/pd4ml/PD4ML.html#addMetadata-java.lang.String-java.lang.String-boolean-

Document creator property can be overridden only via dedicated environment variable.

#33994

I have a couple of questions regarding converting documents by array of URLs:
1. Is RTF conversion of array of URLs supported in v4? There are separate methods to read and write, and I don’t see any API taking an array or list. I was able to workaround this using PDF merge feature, but probably there is more straight way?
2. Was rendering by array of URLs for RTF supported in v3? PDF works fine for me, but for RTF it takes only 1st document and ignores others. Please see code snippet and resulting rtf file attached.

Attachments:

You must be logged in to view attached files.

#33996

1. Right, there is no possibility to pass an array of URLs or input streams anymore. In our plans to support a possibility to call readHTML() multiple times: to append new docs to already loaded one(s). Before the feature is implemented, you may just merge multiple HTML docs to a single one and pass it to PD4ML at once.

2. It was not supported in v3. A workaround is the same as in #1: merge HTMLs before the conversion.

#33997

Thank you for clarification!

#33998

Hello,

Could you please explain how correlate PageSize and HtmlWidth settings of PD4ML class?
Are there some rules specifying that, for example HtmlWidth should be less than PageSize’s width?
Currently we have the following defaults in our code:
pd4ml.setPageSize(new PageSize(595, 842)); pd4ml.setHtmlWidth(850);

And now we face issues with that defaults for some html files, PD4ML just get stuck and doesn’t reply, no errors are logged. But if I set HtmlWidth to 849 which is still greater than PageSize’s width – everything works fine.

We didn’t face such issues with PD4ML 4.0.9fx1, issue appears when I switch to PD4ML 4.0.9fx2-SNAPSHOT, so I also preparing a sample to report an issue. But I’m wondering if this is correct usage of PD4ML or not, so probably we should modify our defaults as well?

#33999

I’ve reported an issue describing the use case in more details.

#34000

nina_birych wrote:

Could you please explain how correlate PageSize and HtmlWidth settings of PD4ML class?

PageSize is the target page format, which dimensions given in physical units (mm, in, pt etc). htmlWidth can bee seen as a width of a virtual “web browser” frame. htmlWidth is mapped to pageSize.width (minus horizontal margins).

See /pd4ml-v4-programmers-manual/#customizing

nina_birych wrote:

PD4ML just get stuck and doesn’t reply

We’ll analyze and reply regarding the issue via the Helpdesk

#34001

PD4ML wrote:

PageSize is the target page format, which dimensions given in physical units (mm, in, pt etc). htmlWidth can bee seen as a width of a virtual “web browser” frame. htmlWidth is mapped to pageSize.width (minus horizontal margins).

See /pd4ml-v4-programmers-manual/#customizing

Thank you for the link, it made things more clear for me.
So, as I understand, there is no any strict recommendation that HtmlWidth should be less than PageSize.width, it just impacts the scale how PDF is generated (the more HtmlWidth the smaller scale). Correct?

#34002

nina_birych wrote:

So, as I understand, there is no any strict recommendation that HtmlWidth should be less than PageSize.width, it just impacts the scale how PDF is generated (the more HtmlWidth the smaller scale). Correct?

No. htmlWidth value should take into account only the HTML content. Let’s say you have a 1000px-wide HTML table. If you define htmlWidth=850, the not fitting 150px of the table are going to be cut in the rendered layout. The visible 850px will be mapped to the target paper width, independently if the format is A1 or A4 or A6.

#34003

Thank you for clarification.
But it should not fail anyway, regardless of htmlWidth value passed. For now I see that different documents are not getting converted with various htmlWidth values (e.g. Doc1 gets converted fine with htmlWidth=842 but gets stuck with 850, Doc2 gets converted with htmlWidth=850 but gets stuck with 842 (or any other), and so on…). Are there any updates on this issue?

#34004

Of course, it should not fail or get stuck depending on htmlWidth value. We plan to address the issue tomorrow – in the last days there was no time frame for work on it. Sorry, this is taking so long.

#34005

Hello,

Could you please provide an update on the issue?
I’m trying daily snapshot builds, but the last one (4.0.9fx2-20201028-0554) still doesn’t work.

Thanks,
Nina

#34006

We observe differences in RTF file content for numerated lists generated in pd4ml v3 and v4. Please note, in view mode they look almost the same, only the files’ content differs.
For example, there is a list styled to be lowercase-roman:
<ol style="list-style-type: lower-roman;"> <li> <div>Inner 'li' tag 1.1.1</div> </li> <li> <div>Inner 'li' tag 1.1.2</div> </li> <li> <div>Inner 'li' tag 1.1.3</div> </li> </ol>

When used pd4ml v3, the last list item in RTF file is stored as below (if open in lister or notepad):
}}}\ql\par}\f2\i0\b0\fs20\ql{\pard \plain \f2\i0\b0\fs20\nowidctlpar{\*\hyphen2\hyphlead2\hyphtrail2\hyphmax0}\cf1\kerning1\hich\dbch\loch{\listtext\pard\f2\i0\b0\fs20\plain iii. }\ilvl2\ls3 \li1440\ri0\lin1440\rin0\fi-360{\rtlch \ltrch\loch\f2\i0\b0\fs20 {\pard\ql\li0\ri0\sl208\slmult0{\widctlpar\dbch\ql\cf1 Inner 'li' tag 1.1.3

Please see there is triple i there iii.

With pd4ml v4 the same list item is stored as:
}}}\ql\par}\f1\i0\b0\fs20\ql{\pard \plain\ltrpar\ltrch \f1\i0\b0\fs20\nowidctlpar{\*\hyphen2\hyphlead2\hyphtrail2\hyphmax0}\cf1\kerning1\hich\dbch\loch{\listtext\pard\ltrpar\ltrch\f1\i0\b0\fs20\plain i. }\ilvl2\ls3 \li1440\ri0\lin1440\rin0\fi-360{\ltrpar\ltrch\loch\f1\i0\b0\fs20 {\pard\ltrpar\ltrch\li0\ri0\sl250\slmult0{\widctlpar\dbch\ql\ltrch\f1\i0\b0\fs20 Inner 'li' tag 1.1.3

There is only single i there.

Also, I’ve noticed that view mode in WordPad displays them differently as well.
While in view mode in MS Word application both documents are displayed properly with iii. (the difference was found by automated tests), so I’m just wondering to confirm this is expected behavior in v4.

Please see sample html, resulting rtf files and java code attached.

Attachments:

You must be logged in to view attached files.

[Author]

Posts