Completed
Last Updated: 16 Nov 2021 11:45 by ADMIN
A.
Created on: 08 Oct 2019 14:35
Type: Bug Report
15
Telerik.Reporting PDF issues in Linux (Docker)

Hello Telerik team!

In the attachment, there are two PDFs, generated by the same template (also in attachment): one built under Windows, another one - under Linux (Docker). See red boxes as defects on the screenshot:

Text wrap issues

Text wrap issues

Dockerfile fragment:

# MS TrueTypeFonts install
RUN wget http://ftp.de.debian.org/debian/pool/contrib/m/msttcorefonts/ttf-mscorefonts-installer_3.6_all.deb -P ~/Downloads
RUN apt install -y ~/Downloads/ttf-mscorefonts-installer_3.6_all.deb

RUN apt-get install -y libc6-dev
RUN apt-get install -y libgdiplus
RUN apt-get install -y libx11-dev
RUN rm -rf /var/lib/apt/lists/*

 

Please help us to resolve these issues in Linux.

Attached Files:
17 comments
ADMIN
Ivan Hristov
Posted on: 16 Nov 2021 11:44

Hi all,

In our 2021 R3 SP1 release we've made some improvements of the way libgdiplus measures text and counts characters. We would like to thank Sparky for the detailed research he did and the smart solution he provided about upscaling the measurement area and font size before the actual measuring and downscaling the result afterwards. This indeed produced more correct results, but unfortunately didn't help with the other major problem we stumbled upon - the incorrect character counting, explained earlier in this thread. Since it doesn't seem likely that this issue will be resolved in a future version of libgdiplus library, we handled it on our end. The combined effect of those two fixes now allows to render reports that are much closer to the layout they have when rendered on Windows, as you can see in the attached screenshots.

Although it's not in our immediate plans, we strongly consider replacing libgdiplus with SkiaSharp, as mentioned by my colleague. Given the complexity of such task, I'm sure you'll understand that completing it will require considerable amount of time. However, we can ensure you that we'll continue providing fixes for issues caused by the libgdiplus implementation in a continuous effort to improve our rendering regardless the platform.

It will be awesome if you try the 2021 R3 SP1 release and share the results here or through our support system. Thank you all again for your patience and especially to Sparky for the dedication and provided insight. We really appreciate it!

Ivan Hristov

Reporting Team

ADMIN
Todor
Posted on: 16 Jun 2021 10:10

Hello Sparky,

Thank you for the extensive investigation of the problem. The multiply-divide workaround is very clever and it seems it will resolve some of the measuring issues that we experience using Cairo. As you mentioned, SkiaSharp is the library that should perform better than libgdi+ and we've actually considered using it for non-Windows graphics manipulations. However, the transition from GDI+ usages to SkiaSharp will take some time, so for the time being we'll try to patch up the libgdi+ bugs in order to ensure a bit better text and image rendering.
Thank you again for your time and efforts.

Regards,
Todor
Progress Telerik

Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Sparky
Posted on: 09 Jun 2021 11:02
The simplest and fastest solution is to measure the text with multiplying font size and bound box for measurement by 32-128 and then dividing back the result by the same amount - it is not nice, but it works great. This method works for all output formats when system.drawing is used only for mesurement and the text rendering is not done with system.drawing.

I've spent several days trying to see what is wrong in libgdiplus/cairo/pango, and I can say that the problems are so deep buried that they are almost impossible to resolve, if cairo is used as backend for libgdiplus. cairo (the back-end) uses fixed 24.8  32 bit math which is not enough for good text metering. And cairo is really hard to rebuild to use for example 48.16 64 bit math, or straight double precision floating point math (even single precision would do). Not to mention that font rendering on image (as you use it for metering) does not support subpixel glyph positions and it seems that it will never will.

Consider trying SkiaSharp in the future. Even Microsoft no longer recommends System.Drawing for new designs. It is a shame, but that's the way it is.

There are also FreeType and several other ports for .net that can be used for font metering without having libgdiplus/pango/cairo defficiencies, which, IMHO, will never be resolved.
ADMIN
Todor
Posted on: 09 Jun 2021 10:18

Hello Sparky,

I'm afraid that the described behavior is entirely due to the GDI+ implementation for the Linux environment, which is outside of our control. We hope the contributors to the libgdiplus package would tune it up, which should improve also the layout of our reports under Linux. Unfortunately, I'm not aware of any settings that may fix the known measurement errors.

Regards,
Todor
Progress Telerik

Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Sparky
Posted on: 02 Jun 2021 15:22
...Is there something new oin this respect? We observe the same artifacts when using Telerik reporting in Linux container - some texts aremoved to the oleft or right, some penetrate into the neighbouring cells in a table report, rendered to PDF. With libgdi6, built with pango, the thing are even worse - the fonts are rendered 3 times smaller, and the rest of the report is rendered 2-3 times higher.

I there something I can do (like settings for libgdi+ ot something similar)?
ADMIN
Ivan Hristov
Posted on: 07 Jul 2020 12:09

Hello Jonathan,

I can confirm 

that the problems with the incorrect rendering are caused by the libgdiplus library, and specifically - by the implementation of MeasureString method. We use this method to determine how many characters can fit in certain area, for example - in a textbox bounds, and render the text contents based on that measurement. I examined the behavior of MeasureString when measuring the "Consolidated Fund" string in both Windows and Linux and clearly on Linux the measurement is wrong, as I will explain below in details:

When measuring the string "Consolidated Fund" in the bounds of its corresponding textbox, the Graphics library correctly determines it would fit on two lines. However, the measurement claims that on the first line only 11 characters will fit, which is exactly the "Consolidate" chunk. The rest of the string will move on the new line and this is why you see it rendered like "Consolidate\r\nd Fund". Of course, on Windows the same code returns results as expected - the first line would fit 12 characters and the rendering looks OK.

But this is not the strangest thing with the libgdiplus behavior. Actually when measuring shorter string, like "Consolidated" or even "Consolidated F", the measurement works fine - claims that the first line would fit 12 characters like in Windows. Apparently the problem occurs when the string needs to be split on more than one line - in such case the first line loses a character. At the same time on Windows the same code returns consistent results with the same parameters passed to MeasureString() method.

Unfortunately I'm unable to provide a workaround for this scenario, because, as you see, we're using a 3rd party library as Graphics replacement and we do not maintain its code. In the libgdiplus github repo there are a few bugs related to incorrect string measurement and I hope this issue will also be fixed in a future release of libgdiplus package. Besides that we're examining different options for the parameters passed to MeasureString method to see if there is a setting that would perform the word wrapping more correctly. Rest assured that if we achieve any success at that, we'll post it here and include it in the next version of our product.

 

Regards,

Ivan Hristov,

Telerik Reporting Team

Jonathan
Posted on: 30 Jun 2020 18:39

I installed the latest libgdiplus using the instructions that Mark referenced to get it from the mono repo, and it doesn't seem to address some text-wrap issues I am seeing.

libgdiplus version is 6.0.5-0xamarin1+debian10b1

It looks like the Arial text is rendering very closely to Windows (or perhaps exactly the same, I can't see any differences at 150% zoom), but there are some baffling wrappings happening in Linux that I don't see in Windows. We can solve the disappearing text boxes by turning off CanGrow, but it's not clear why it needs to grow in the first place.

 

Attached Files:
Mark
Posted on: 04 Dec 2019 14:00

Thanks. I was able to get it installed by adding the mono-project repo to the apt sources, as per: https://www.mono-project.com/download/stable/#download-lin

Then running > sudo apt-get install libgdiplus

 

ADMIN
Nikolay
Posted on: 04 Dec 2019 11:11

Hello Mark,

We are in the process of testing with the latest version of libgdiplus on Ubuntu.

If you want to try by yourself here are the steps: 

  • Prerequisites: 

We are assuming that you already have older libgdiplus which installed its dependencies. More information and build and install instructions can be found here: https://github.com/mono/libgdiplus

>sudo apt install libgdiplus
  • On Debian based distributions install prerequisites by running this command:
>sudo apt-get install libgif-dev autoconf libtool automake build-essential gettext libglib2.0-dev libcairo2-dev libtiff-dev libexif-dev
  • Clone or download and unarchive libgdiplus repository:
>git clone https://github.com/mono/libgdiplus.git
>cd libgdiplus
  • Run build script (Optionally you can use '--with-pango' parameter if you want to use this library:
>./autogen.sh
>make 
  • Then run unit tests to verify of all is correct: 
>make check

If everything is fine, install by running: 

>make install 

or  

>sudo make install

If the first one fails because of missing rights.

 

We will appreciate your help if you send us a specific report in trdp or trdx format that will help us reproduce the issue and test with the newer libgdiplus. 

Regards,
Nikolay
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Mark
Posted on: 03 Dec 2019 13:59
That's very interesting news. As you probably know, libgdiplus 6 is not available through apt-get repos. The only instructions I have found as to how to install it are exceedingly complicated, and I am not confident of my ability to do so. How did you go about installing?
ADMIN
Nasko
Posted on: 03 Dec 2019 07:56

Hello Mark,

We tested using libgdiplus 6 (with and without pango) and there is an improvement in the measuring and rendering behavior. We tested specific scenarios that would usually result in incorrect measurements, but we were unable to observe an issue with the new version of the library. We are positive that you would see an improvement if you upgrade your system configuration to use libgdiplus 6 or newer.

Regards,
Nasko
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Mark
Posted on: 02 Dec 2019 13:05
I do not have the ability to do so. I was just suggesting it as a possibility.
ADMIN
Nasko
Posted on: 28 Nov 2019 10:37

Hi Mark,

We do not require a specific version of libgdiplus, so testing with a newer libgdiplus release would be the most promising option to fix the measurements. Let us know if it helps in your particular scenario.

Regards,
Nasko
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Mark
Posted on: 21 Nov 2019 14:52

To amend to what I just said.

I just noticed that the apt repo in Ubuntu and Debian (and may be others) only has libgdiplus 4.2, which is from 2015. However. 6.0.x of libgdiplus is out and is still being actively maintained (last release was October). I wonder if using libgdiplus 6.0 would have some effect?

Mark
Posted on: 21 Nov 2019 13:40

We have the same issue, and find it extremely difficult to debug and fix because the report developers are, of course, on Windows machines using the Report Builder, while the report runs on Linux. So the report developers never see any issues, making it very difficult to know what minor tweaks are needed to make the report look right.

But perhaps the answer is not finding "other libraries", but rather, for Telerik/Progress developers to work with Mono-Project developers to improve libgdiplus https://github.com/mono/libgdiplus. That's the very spirit of open source development.

Gregor
Posted on: 22 Oct 2019 11:37

I've the same problem !!

Please investigate in fixing this.

I really need this shortly.

 

Best regards

Gregor

ADMIN
Nasko
Posted on: 09 Oct 2019 14:29

Hello A.,

In Windows we depend on GDI+ to do the measurement of text. In Linux we are entirely relying on libgdiplus to do the same measurements and we layout the report items according to the resulting measurements. Unfortunately, there are discrepancies in measuring between GDI+ and libgdiplus which is the reason for the defects shown in the provided screenshots. To improve this behavior we will be researching and testing other libraries to do the needed measurements.

Regards,
Nasko
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items