#28651

other problèmes with this code :

[language=html:2i7d58zk]

---

test

---

test
test
test
test
test[/language:2i7d58zk]

there is no underscore for the first test message.

#28649

In the case first you need to use Xalan or other XSLT transformer to produce HTML from the source XML/XSL.

You may find some useful hints in the sources of Dxl2Pdf, which converts DXL to HTML. http://pd4ml.com/command-line-dxl-to-pdf-converter.htm

#26606

Hi.

I am rendering af URL and have problems with characters like æ, ø, å which is shown as ‘?’.

How do I solve the character problem?

My HTML page is declared with the meta tag:

The pd4ml debug looks like:
version: PD4ML 371b9 (eval)
using content encoding from HTTP header: iso-8859-1
new parse attempt with: UTF8
done in 240ms.

In the PD4ML code I use the code:
<br /> ...<br /> PD4ML html = new PD4ML();<br /> html.overrideDocumentEncoding("iso-8859-1");<br /> html.enableDebugInfo();<br /> <br /> response.setContentType("application/pdf");<br /> response.setHeader("Content-disposition","inline; filename="+fileName+".pdf");<br /> <br /> InputStreamReader isr = new InputStreamReader(connection.getInputStream());<br /> ByteArrayOutputStream baos = new ByteArrayOutputStream();<br /> html.render( url, baos );<br /> <br /> byte[] result = baos.toByteArray();<br /> response.setContentLength(result.length);<br /> <br /> ServletOutputStream sos = response.getOutputStream();<br /> sos.write( result );<br />

#28656

PD4ML supports by default ISO-8859-1 charset only. In order to output international characters you need to utilize TTF embedding feature of PD4ML Pro.

pd4ml-html-css-pdf-tips-tricks-f7/ttf-embedding-t42.html

#28657

Thanks.

But the characters like æøå is supported by ISO-8859-1.

And why does the debug says that it parse with attempt: UTF8?:
using content encoding from HTTP header: iso-8859-1
new parse attempt with: UTF8

Please see:
http://en.wikipedia.org/wiki/ISO/IEC_8859-1

#28658

new parse attempt with: UTF8
is caused by an encounter with encoding directive.

In your code overrideDocumentEncoding() takes no effect, as if works only for render(URL) methods.

[language=java:2s69vyt0]/**
* sets default encoding for URL-addressed HTML documents
* @param encoding name
* @since v3.7.1
*/
public void overrideDocumentEncoding( String encoding ) {[/language:2s69vyt0]

As long as you pass the HTML source as an InputStreamReader, it uses a charset of the reader. You may try to use InputStreamReader constructor with Carset parameter. But a better approach would be to call
render(StringReader isr, OutputStream os, URL base, String encoding)

> But the characters like æøå is supported by ISO-8859-1.
Obviously the problem is caused by an attempt to interpret ISO-8859-1 document as UTF-8. First we need to make sure it is parsed as ISO-8859-1. Please try the above suggestions.

#28659

Thanks, I will try your approach.

But how do we convert the website url to java.io.StringReader if we are not going to use java.net.URLConnection?

And what is the java.net.URL base for?

Can you please give some tips?

#28660

> And what is the java.net.URL base for?

base is for relative path calculations. InputStreamReader or StringReader simply provide no info to resolve relative paths.

Well, in your sample code it is not quite clear where connection variable comes from. If your source document can be addressed by URL, it is good idea to use one of render(URL) methods. In the case html.overrideDocumentEncoding(“iso-8859-1”) should work for you as expected.

#28307

I have the same problem.
It works on the http:\localhost.

image not yet in cache: http://localhost:9084/test/AttachmentServlet?attachId=43
not yet in cache: http://localhost:9084/test/AttachmentServlet?attachId=43
then it calls the servlet and returns the image
image size: 137480

but when I try it on the server:

image not yet in cache: https://ddltest.xxxx.com/test/AttachmentServlet?attachId=43
not yet in cache: https://ddltest.xxxx.com/test/AttachmentServlet?attachId=43
image size: 12289
image type of https://ddltest.XXXX.com/test/AttachmentServlet?attachId=43 is unknown.
can not load image: /test/AttachmentServlet?attachId=43

I don’t see the server version calling the Servlet.

Please help.

#28661

Sorry my mistake.

We are not using java.net.URLConnection. We only use:
html.render( url, baos );

Here is how we get the URL:
java.net.URL url = new java.net.URL(“http://www.cateringportal.dk/rekvisition/servlet/URLOrder?orderID=279&uid=uJ5FOxxyXCgMvU42ygSRqdBlmWLPGzVw7JiAqOsTPnhv8MirBa”);

#28652

The problem with combined underline and line-through CSS styles (or corresponding HTML tags) has just been fixed in the development build. Now it also supports overline text decoration. To be available with the forthcoming beta release.

We’ll address the rest of the issues tomorrow.

#26607

Hi,

In terms of performance and memory usage, is it better to use the pd4ml jsp transform tag or is it better to use PD4ML API calls in servlet code? Does it make any difference?

Secondly, if multiple website users are going to generate pdfs (using the pd4ml transform tag) from the same jsp source code at the same time is this a problem? In the servlet created from the compiled jsp (that uses the transform tag) I saw that the org.zefer.pd4ml.taglib.PD4MLTransformerTag variable was created as a local variable in the service method and therefore should be thread-safe, right?

I would be very grateful for your advice.

Thanks,
Josh

#28653

Thanks for your reponse.
When will this beta be available ?

thanks.

#28663

1. PD4ML JSP taglib is a lightweight wrapper for PD4ML API – from resource consumption perspective it makes almost no difference which approach is in use. However we recommend to use the taglib where possible, as it implicitly solves some HTTP-specific issues you may face using “naked” PD4ML API in webapp scenarios (it sets correct cache control HTTP headers to avoid failures of particular combinations of MS IE+Acroread etc)

2. PD4ML is thread safe (the shared internal resources are protected from race conditions and dead locks), but its methods are not re-enterant: you should not call render() methods of a single PD4ML instance from multiple threads simultaneously. The best practice would be to create a new PD4ML instance for each conversion request. Multiple PD4ML instances may work safe in parallel, but you should take into account – HTML rendering is a resource consuming task. Too many processes may take too many system resources.

Here is some useful info about:
http://pd4ml.com/performance.htm

#28654

We planned to release it this week. Probably it will take a couple days more.

Regarding the remaining issues:

1. The background style will work if you change to . We’ll try to make it working for too.

2. In order to output texts with Impact font face, you need to utilize TTF embedding feature of PD4ML Pro:
pd4ml-html-css-pdf-tips-tricks-f7/ttf-embedding-t42.html

[Author]

Posts