Bug #3619

Bug #3365

Added by Michael Shestero over 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Note that my problem at Bug #3365 ( ) was never been solved.

I wonder why you set it "resloved" status.


Updated by Michael Shestero over 8 years ago

I can simplify the case:

If I convert the quite simple table with Russian text to PDF only the first page in PDF are correct; in all other pages the letters are eaten. This is critical for me.

I see "WString: narrow(): loss of detail: ..." console warnings but looks like it correspond not to every string constants in the source; looks like they are only related to the those last cells that are at the second and next pages in PDF.

I don't change the font now; font is default. Don't feel like this is a font problem.

Although also sometimes I see message from libHaru "cannot load the font arial.ttf - expecting correct TrueType font" or something like that (this is another feature of the bug). I suspect I know why it's happened: Wt calls libHaru function to load this font several times; as I noticed libHaru gives the error if you try to load the font that was already loaded before.


Updated by Koen Deforche over 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche
  • Target version changed from 3.3.3 to 3.3.4


Can you provide the HTML that does not work for you?




Updated by Michael Shestero over 8 years ago

Sorry for long silence.

See u.html in issue #3365.

You can multiply any row in the table to make in long enough for several pages in PDF.

You can also create any simpliest table HTML to prove it.

By the way, you just close this issue. Why? It is not resolved!


Updated by Koen Deforche about 8 years ago

  • Status changed from Feedback to Closed


You need to use a more recent version of libharu than its last release (e.g. the github version).


Also available in: Atom PDF