RTF features

#26650

Hi,
I have been using PD4ML successfully in our product (volume license) for a while now creating PDFs – it’s a great! With an increased demand to also export to Word, I am excited that you have implemented RTF export as well. However, I have come across some challenges:

Headers and footers
I am not able to control the height of header/footer. Also I am not able to use multiple headers/footers – it seems that the last used will be on all pages regardless. Looking at the RFT spec, the format seems rather limited, but I see that it is possible to have a different footer/header on the first page (headerf) which I would assume is the most common need.

Margins
I am not able to control any margins. Looking at the generated RTF, page margins are printed out, but is it a way to control this in the template, e.g. through the body? This is how it looks in a text editor, also showing paper height and width:

paperw11900paperh16840margl800margr400margt400margb400

I believe it should be possible to do this on a paragraph level in RTF.

Unwanted line breaks
When I put e.g. tables on top of each other, I always get additional space below. Here is a simple example:

Before table

Table1

Table2

After table

As you will see, you get two unwanted line breaks between the tables, as well as one below the second table before the text. It looks like the paragraphs in the RTF are causing it. Looking at some examples online, I am able to modify the RTF to work as I want. This is done by rather starting with pard instead of par, but then make sure that all text block, like “Before table” is done like this:

{pard Before table par}

Without the syntax on either side of the text, the table will bleed onto it. Further, I have modified the table syntax where I start with pard (and no par):

{pard
trowd…..
…
}

I am by no means an expert in RTF, and I completely understand if these things can’t be accomplished. But please take it into consideration, as I feel a bit helpless at the moment with the issues listed. Will these things be part of a release do you think, and if so, approximately when?

Here is the modified RTF that has no additional breaks:

{rtf1
{info
{title }
}
paperw11900paperh16840margl800margr400margt400margb400widowctrlf1i0b0fs16{fonttbl{f1 Times New Roman;}
}
{colortbl;red0green0blue0;
}
{lisb30widctlpar{widctlparcf1f1i0b0fs26 {pard Before table par}
{pard
trowdtrrh385clvertalcclbrdrtbrdrsbrdrw17clbrdrbbrdrsbrdrw17clbrdrlbrdrsbrdrw17clbrdrrbrdrsbrdrw17clpadl17clpadr17clpadt17clpadb17clpadfl3clpadfr3clpadft3clpadfb3clshdrawnilcellx803pardintblcf1 Table1plaincellpardintblrow
}
{pard
trowdtrrh385clvertalcclbrdrtbrdrsbrdrw17clbrdrbbrdrsbrdrw17clbrdrlbrdrsbrdrw17clbrdrrbrdrsbrdrw17clpadl17clpadr17clpadt17clpadb17clpadfl3clpadfr3clpadft3clpadfb3clshdrawnilcellx803pardintblcf1f1i0b0fs26 Table2plaincellpardintblrow
}
cf1f1i0b0fs26 {pard After table par}
}
par}}

#28769

In few days we plan to release a new PD4ML version which addresses the issues. Below are our comments:

> I am not able to control the height of header/footer.
Unfortunately RTF format does not allow to control header/footer height. I would recommend to define header/footer as a table, with an explicitly given height matches the desired header/footer height.

> Also I am not able to use multiple headers/footers – it seems that the last used will be on all pages regardless.
> Looking at the RFT spec, the format seems rather limited, but I see that it is possible to have a different
> footer/header on the first page (headerf) which I would assume is the most common need.
You are right, it is possible to define a different page header/footer for a title page only. In the new version you may define such header/footer that way:
[language=java:3446b1pr]PD4PageMark header = new PD4PageMark() {
@Override
public String getHtmlTemplate(int pageNumber) {
if ( pageNumber == 1 ) {
return “Title page. $[title]“;
}
return super.getHtmlTemplate();
}
};
header.setHtmlTemplate(“Page $[page]”);
pd4ml.setPageHeader(header);[/language:3446b1pr]
Unfortunately there is still no way to define title page header/footer with tag.

> I am not able to control any margins. Looking at the generated RTF, page margins are printed out,
> but is it a way to control this in the template, e.g. through the body?

Now you may define margins via API call
[language=java:3446b1pr]pd4ml.setPageInsets(new Insets(20,40,20,20));[/language:3446b1pr]
via margin CSS property of element or combined. CSS way does not impact page header/footer positioning, the API call does.

> Unwanted line breaks
We suppressed the line breaks were it was possible.
Note: RTF tables do not allow to define top and bottom margins. If HTML source defines the margins, PDF output blank lines instead of them.

#28770

Hi again, and thanks for the last release – it fixed a lot of the issue I was facing 🙂

Since then I have been struggling with controlling table cell height. At first I thought it was due to some line breaking, and I had some success ending line breaks with / like this
. But it never really fixed it, as I randomly got space at the end of the TDs. Now, after looking into it again, I realized that this might not have been the case at all, that the excessive space is in fact due to a table row height being set – probably calculated in some way. Here is the produced RTF, notice the trrh1073:

trqltrowdtrrh1073clvertaltclbrdrtbrdrnil

If I remove it from the line, it fixes all my problems! The question is, can I control this with a tag, a css attribute or turn if off with an API setting?

Regarding your comment about being able to set header/footer as a tag not being implemented yet, will it be possible in the future? If so, do you have a rough estimate to when we can expect that?

Lastely, when specifying lengths in css (or tags), what is the unit that I should use (besides %)? I know that RTF natively operates on a twips, and I tried to calculate it from cm, but without much luck.

#28771

We’ll check what could be done there.
It looks like a mismatch of dimentions, calculated during HTML layouting, and factual dimensions in RTF documents.

A fix can take 1-1.5 weeks.

#28772

@PD4ML wrote:

We’ll check what could be done there.
It looks like a mismatch of dimentions, calculated during HTML layouting, and factual dimensions in RTF documents.

A fix can take 1-1.5 weeks.

Thanks. Let me know if you need any beta testing 🙂

#28773

It seems we fixed the issue. If you’d like to test it with the current development build – please request it by email from support pd4ml com

#28774

@PD4ML wrote:

It seems we fixed the issue. If you’d like to test it with the current development build – please request it by email from support pd4ml com

The spacing issue seems to be working fine now, thanks for that!

Regarding the two other questions I had, do you have any feedback for me on that?

@rnilsen wrote:

Regarding your comment about being able to set header/footer as a tag not being implemented yet, will it be possible in the future? If so, do you have a rough estimate to when we can expect that?

Lastely, when specifying lengths in css (or tags), what is the unit that I should use (besides %)? I know that RTF natively operates on a twips, and I tried to calculate it from cm, but without much luck.

#28775

> Regarding your comment about being able to set header/footer as a tag not being implemented yet, will it be possible in the future?
> If so, do you have a rough estimate to when we can expect that?

The feature implementation has quite a low priority. You know, the main purpose of PD4ML is PDF output. Normally we add new features to RTF module when there is no urgent PDF issues. I have my doubts if we’ll have a chance to start the implementation till May.

If you need the feature urgently you may fund its implementation. In the case please contact us by email.

> Lastely, when specifying lengths in css (or tags), what is the unit that I should use (besides %)?
> I know that RTF natively operates on a twips, and I tried to calculate it from cm, but without much luck.

In RTF output mode PD4ML still uses HTML renderer, developed for PDF output.

It is explained by the link: http://pd4ml.com/cookbook/pdf_page_formatting.htm

That means you get HTML layout of requested width (htmlWidth parameter) mapped to chosen paper format. An actual transformation from dimensions given in screen pixels or in physical units to resulting dimensions on paper is not always obvious.

pd4ml.protectPhysicalUnitDimensions() API call should make dimensions/sizes given in pt, in, cm keept intact.

There some are other support topics address the issue. I.e.
html-css-to-pdf-rendering-issues-f3/font-size-wierdness-t109.html

[Author]

Posts