pdfCreatePagesGroup working on Windows but not on Linux

AbsoMFilion

Hi,

We have problem with the pdf-utils pdfCreatePagesGroup method. On our local machine on windows, it works without problem but on our dev or production environment running on linux, the group is never created.
We have some log showing the $pdf.pages object on our windows machine vs our linux machine using the same code :

windows:

// console.log(this.$pdf.pages): 
Object [
  { group: undefined, items: Object [] },
  { group: { name: 0 }, items: Object [] },
  { group: { name: 0 }, items: Object [] }
]

linux:

// console.log(this.$pdf.pages): 
Object [
  { group: undefined, items: Object [] },
  { group: undefined, items: Object [] },
  { group: undefined, items: Object [] }
]

The code to create the group:

{{#each items}}
    {{{pdfCreatePagesGroup name=0}}}
    ...
{{/each}}

We did some debugging and the <span> with the group information is outputted to the document on both windows and linux as per this log line:

Pdf utils adding group hidden field <span style='opacity: 0.01;font-size:1.1px'>group@@@eyJuYW1lIjowfQ==@@@</span>

We noticed that on windows we have the following log line, but not on linux:

Pdf utils invokes merge with group [object Object]

We followed the code on where this line is logged and we think the problem either comes from the getPageText() call or the parseGroup() function in https://github.com/jsreport/jsreport-pdf-utils/blob/master/lib/utils/parsePdf.js

We are using the ChromePdf recipe and the handlebars engine.
We are running the latest nuget packages available (jsreport.AspNetCore 2.0.0, jsreport.Local 2.0.0, jsreport.Binary.Linux 2.2.2, jsreport.Binary 2.2.0). Here is the code we use in the startup.cs :

var jsReport = new LocalReporting()
    .UseBinary(RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? jsreport.Binary.JsReportBinary.GetBinary() : jsreport.Binary.Linux.JsReportBinary.GetBinary())
    .RunInDirectory(RuntimeInformation.IsOSPlatform(OSPlatform.Linux) ? "jsreport" : null)
    .KillRunningJsReportProcesses()
    .Configure(config => config.AllowedLocalFilesAccess().FileSystemStore())
    .AsWebServer()
    .Create();
services.AddJsReport(jsReport);
jsReport.StartAsync().Wait();

Do you have any idea what could cause the group to be undefined on linux?

Thanks

jan_blaha

Thank you for the verbose problem description.

Initially we had problem finding html element that is invisible to the eye but still part of the pdf.
Finally we found <span style='opacity: 0.01;font-size:1.1px'>xxxx</span> to fulfill our needs in stable way.
Maybe in your case, chrome together with some particular linux fonts make the group element completely invisible and chrome skips it in the pdf. This would mean we are also not able to read it from it and result with undefined group.
This would make me unhappy. However the pdf utils runs in productions for a year and no complain on this so far.

Lets try to eliminate the possible problem the first. Can you try to run this on your server and check if it works or not?
It is the most simple pdf utils and group usage.
https://playground.jsreport.net/w/jan_blaha/0Qenv2ME

jan_blaha

I forgot to add some theory to make the above more sense.
If you add a group, we put to the html an almost invisible element with the group value.
When chrome converts html to pdf and the pdf utils merge operation runs, we parse the pdf into text form and find the value of this element. That is then decoded and provided to your template which runs as pdf utils operation through this.$pdf...

AbsoMFilion

Hi @jan_blaha

Thanks for the quick answer. I did some more tests using the sample you gave me and I found some interesting things.

I tried the template on both computers (my windows dev workstation and our linux server) and even your sample don't work on linux.
With your information of pdf-util parsing the pdf to text, I tried converting both pdf to text using poppler-utils and i got these outputs:

Windows:

header
mainfoo
content
group@@@ImZvbyI=@@@

Linux:

header
main content
g ro u p @@@ImZ v b y I= @@@

As you can see, on linux there are some strange spacings between the letters. No wonder the regex is not able to match the group.

I have absolutely no clue why chrome is rendering it that way though.
Do you have any idea on what we could try ?

Thanks

jan_blaha

Could you upload the pdf from linux?
You can control paste here, or somewhere else and share the link.

AbsoMFilion

Here it is:
https://we.tl/t-79Y3xe3h64

I had to use wetransfer, because I had an error trying to upload it here.

Thanks

jan_blaha

Thanks, I take a look....

It is something specific about your server, however not sure what it can be.
Maybe you could try to install these packages:
https://github.com/jsreport/jsreport/blob/master/docker/full/Dockerfile#L10
https://github.com/jsreport/jsreport/blob/master/docker/full/Dockerfile#L35
You can also find some hints what should be installed in the other distributions here
https://jsreport.net/on-prem

I guess this wan't satisfy you. However if you have an option to use docker, you would probably not have these issues with it.

AbsoMFilion

Thanks a lot for your help.

We'll see what are our options here.
Your help was really appreciated though!

jan_blaha

Btw I see that the pdf from your linux use
/BaseFont /DejaVuSans
and pdf from playground ubuntu uses
/BaseFont /LiberationSerif
So maybe the specific linux fonts are really the issue, however I don't make a conclusion from this.

AbsoMFilion

I tried installing the package fonts-liberation2 on ubuntu and now the group works so it looks like it is a problem with the font.
We are using Lato and Poppins fonts in our reports and it seems they are not rendered correctly to be used for the groups.
We fixed our problem by adding a style in our css to force the liberation font for the pdfCreatePagesGroup span like this:

.pdf-group span {
    font-family: liberation;
}

and in the content.handlebars we do this:

<span class="pdf-group">{{{pdfCreatePagesGroup name=9}}}</span>

That forces the group span to use the liberation font and render correctly!

Thanks for your great help!

jan_blaha

Thanks for sharing.
We will consider adding font-family: liberation; directly to the span for the future versions.