Progress® Telerik® Reporting Feedback Portal
Back to Feed
Request a Feature Report a Bug
Completed
Last Updated: 31 Jan 2024 17:38 by ADMIN
Release 2024 R1 PI1
Levi
Created on: 29 Sep 2021 21:57
Type: Feature Request
54
Future of Linux support for reporting

What's the long-term plan for supporting Linux and Telerik Reporting? The dotnet design team is looking to remove support for System.Drawing.Common on Linux platforms. They're recommending compiler warnings in .Net 6, and full PlatformNotSupportedExceptions in .Net7

 

Sources:

designs/system-drawing-win-only.md at main · dotnet/designs (github.com)

Breaking change: System.Drawing.Common only supported on Windows - .NET | Microsoft Docs

71 comments
ADMIN
Milen | Product Manager @DX
Posted on: 31 Jan 2024 17:38

Hi,

To Adam and whoever this is needed. With the 2024 Q1 release, you can now render reports generated by a remote reporting engine deployed on Linux onto a client machine using embedded WinForms or WPF viewer. Give it a try and tell the rest how this works for you. Thank you for using our tools!

Regards,
Milen | Product Manager @DX
Progress Telerik

Stay tuned by visiting our roadmap and feedback portal pages, enjoy a smooth take-off with our Getting Started resources, or visit the free self-paced technical training at https://learn.telerik.com/.
ADMIN
Ivan Hristov
Posted on: 18 Jan 2024 10:24

Hello Jonathan,

Thank you for this excellent question. Currently, Standalone Report Designer works only with GDI graphics engine, but it makes perfect sense to allow switching to Skia for the reasons you've mentioned. This task depends on the implementation of the runtime switching of graphics engine we discussed earlier in this thread. However, since it presents a new functionality, I have logged it on your behalf in a new feedback item that you can see and vote for here: https://feedback.telerik.com/reporting/1637773.

I have logged it for further discussion with the development team and will keep you informed post updates in the mentioned thread.

Regards,

Ivan Hristov

Telerik Reporting

Jonathan
Posted on: 17 Jan 2024 14:09
Will it be possible to configure the stand-alone report designer to use the Skiasharp rendering engine when generating export files from the preview? This would help us verify that what we see at design-time is similar to what is being generated at run-time. Currently we have to copy report files into a Linux docker container to perform this type of testing.
ADMIN
Ivan Hristov
Posted on: 17 Jan 2024 13:50

Hi folks,

Today we've published a prerelease build for our 2024 Q1 major release, which should be accessible from your Telerik user accounts. The release has version 2024 Q1 PI1 18.0.24.116, where PI stands for 'product iteration'.

Among the other goodies that you can read here (https://www.telerik.com/support/whats-new/reporting/release-history/progress-telerik-reporting-2024-q1-pi1-18-0-24-116), it also brings support for WPF, WinUI, and WinForms viewers, connected to a Reporting REST Service that uses Skia as graphics engine. We decided to pull the development of this feature earlier than initially planned, so you'll have a better coverage of the Skia-supported rendering extensions.

We'll appreciate it if you give it a try and share your feedback.

Regards, Ivan Hristov

Telerik Reporting

ADMIN
Todor
Posted on: 06 Dec 2023 15:07

Hello Adam,

As I explained in the support ticket you opened on the same problem, the error is expected, as with the Skia graphics engine we support PDF, OpenXML, Image, and CSV renderings. The XAML renderings are not supported as specified in the exception message.

The WPF and WinForms desktop viewers should be hosted on Windows and are designed to preview reports rendered on Windows.

Our immediate plans do not include XAML rendering with Skia Sharp. We will discuss this though and update the thread if we update our plans.

Regards,
Todor
Progress Telerik

Stay tuned by visiting our roadmap and feedback portal pages, enjoy a smooth take-off with our Getting Started resources, or visit the free self-paced technical training at https://learn.telerik.com/.
Adam
Posted on: 30 Nov 2023 13:16

Ivan,

 

When we switch to the Skia engine we get that WPFXAMLINteractive rendering format is not available.  Are we missing a step, I thought this was available for the WPF viewer.

ADMIN
Ivan Hristov
Posted on: 17 Nov 2023 09:56

Hi again,

We published our 2023 R3 SP1 release which brings lots of fixes, improvements, and new functionalities (check the Release Notes here). I believe the most important feature for the subscribers of this thread, is the support for OpenXML formats. Our Skia-based implementation now can render DOCX, XLSX, and PPTX files. Along with the Image rendering extension, which is also included in this release, we cover all the export formats we initially planned to deliver on non-Windows platforms.

Of course, we'll continue fixing bugs and improve the rendering engine, so please do not hesitate to share your findings using our support system.

I will update the status of the current thread to 'Completed', but you'll still be able to leave your comments below.

 

Thank you!

Ivan Hristov

Reporting Team

ADMIN
Ivan Hristov
Posted on: 14 Nov 2023 17:41

Hello Vladislav,

Thank you for the project. I confirm there was an issue with multiline text measurement, as shown in the provided report. The issue is now fixed and will be included in our 2023 R3 SP1 release, which will be published in a few hours.

Here's how your report now looks like, rendered in PDF:

... and in HTML5 Report Viewer (running on WSL using latest ASP.NET Core 8.0):

Besides numerous bug fixes and improvements (like removing the dependency on ResXResourceReader.NetStandard package), the 2023 R3 SP1 release will also bring the OpenXML rendering formats (DOCX, XLSX and PPTX) to Skia graphics engine! 

Still, a few features like BackgroundImage support, are not yet fully supported, but we are working on them and will have them delivered in next releases.

Regards, Ivan Hristov

Reporting Team

Vladislav
Posted on: 06 Nov 2023 12:13

Hi Ivan,

Thank you for your response. Your code snipped indeed was the solution to the problem!

I want to report a bug with textBox height calculation when CanGrow == true.


That happens in PDF reports using Skia engine. When I create a textBox, and set multiline string with letters, I expect the textBox to change its height to fit all text automatically. Instead, the new height looks 2 times longer than needed, leaving a lot of empty space.

I'm attaching a demo project that replicates the bug (you can use .\run.ps1 script)

 

Attached Files:
ADMIN
Ivan Hristov
Posted on: 31 Oct 2023 16:59

Hi Vladislav,

This behavior is expected. The serialized entry in the .resx file is a System.Drawing.Bitmap instance, which cannot be used with Skia graphics engine. I guess the .resx file contains a line like this:

<data name="pictureBox1.Value" type="System.Drawing.Bitmap, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">

The exception you see is thrown by the .NET runtime at the moment when the resource reader tries to instantiate the System.Drawing.Bitmap, serialized in the .resx file.

I'd suggest to remove this line and set the pictureBox value using the public method CreateBitmap() we've exposed in the DrawingFactory class:

pictureBox.Value = DrawingFactory.CreateImage(your_skBitmap_instance));

where your_skBitmap_instance is instance of type SkiaSharp.SKBitmap.

 

Regards,

Ivan Hristov

Reporting Team

Vladislav
Posted on: 27 Oct 2023 18:14
I tried to migrate on the Skia engine, but I was faced with a blocker. When there is a PictureBox in the Report (created using VS designer), an exception happens in runtime saying "System.Drawing.Common is not supported on this platform." with stacktrace pointing to a designer-generated line of code
this.pictureBox1.Value = ((object)(resources.GetObject("pictureBox1.Value")));
(I suppose it's about setting a PNG file from .resx to the PictureBox).
Doing the assignment manually looks tricky since you can't use `Bitmap` (windows-only)
I've attached a demo project which replicates the problem. You can use .\run.ps1 to run the app in docker
Attached Files:
ADMIN
Ivan Hristov
Posted on: 18 Oct 2023 21:35

@Dan,

Thank you for your post. It's alright - I completely understand your disappointment. I would feel the same way if a business-critical feature gets constantly delayed.

I'm really glad you managed to make it work on your end. However, installing libgdiplus shouldn't be necessary. I guess libgdiplus package brings some libraries that Skia depends on. Depending on the distro, these libs may be installed with "apt-install libfontconfig1" in your dockerfile.

As for the serialization errors: the engine throws an exception during deserialization stage, because this is the first place it needs to access Skia classes.  This place is the routine that initializes the Unit class, needed to calculate the size of the Report instance and its children. It will be helpful if you can provide the exception stack trace so we can examine it on our end. Taking a look at the dockerfile might also give us some clues what went wrong.

I will appreciate if you create a thread in Reporting Forum space, so the community can read and contribute to the topic. However, if you're concerned about the privacy, please open a support ticket and we'll do our best to help.

Regards,

Ivan Hristov

Reporting Team

Dan
Posted on: 18 Oct 2023 16:55

@Ivan Hristov.

Apologies for my previous post, I was extremely frustrated when I wrote it and should have waited to do so.

 

I can report that we were able to get Telerik Reporting working in AWS/Fargate on .NET 6 using the 'Skia' engine.  I do find it rather odd that I still need to install libgdiplus (via dockerfile). Leaving this out results in serialization exceptions when attempting to load reports.

 

Congratulations on the engine swap, I know that isn't a small feature and what is one line to us is many weeks of work for you and your team.


ADMIN
Ivan Hristov
Posted on: 15 Oct 2023 21:30

Hi folks,

I appreciate the feedback and will try to answer the latest questions:

@Dmytro: Glad to hear it's now working! We'll do our best to get rid of that dependency in PI1 or R1 2024.

@Thomas: Unfortunately I can't reproduce the printing issue on my end, so I will need more information about the configuration, setup, distro, etc. I've tested on my local printer how the HTML5 viewer prints and it works as expected: both in WSL (Ubuntu 22.04) and in Windows environments (using Skia as graphics engine, of course). In both cases I used the Chrome's print dialog. I've tested it also on a virtual printer - no issues as well.

@Sam: Thanks for the additional info about RockyOS. Once we've had it tested, we'll let you know.

Thanks!

Ivan Hristov

Reporting Team

Sam
Posted on: 13 Oct 2023 20:41

Hi Lance,

We are using RockyOS 9.x as a replacement for CentOS. Since it is from upstream RHEL 9.x, there should be no issues, but I thought it worth mentioning.

Cheers,

Sam.

 

Thomas
Posted on: 13 Oct 2023 13:30

Anyone seeing a TypeError when trying to print a report rendered via Skia?  We are seeing the exception below in the console of the browser.

Dmytro
Posted on: 13 Oct 2023 06:59

Hi Ivan,

 

FYI, referencing  ResXResourceReader.NetStandard did the job. Thanks for the help!

 

Dmytro

ADMIN
Lance | Senior Manager Technical Support
Posted on: 12 Oct 2023 17:08

Hello Folks,

In addition to the development efforts, we are also planning our documentation and resources. I've reviewed this thread, along with many public and private conversations, and the main environments we see folks are using are:

  • Debian
  • Ubuntu
  • RHEL/Centos (AWS)
  • CBL-Mariner (Azure containers)

If you are using other Linux variants, please be sure to mention it so that I can add it to our testing and documentation plans. As Ivan mentioned, our next effort is for RHEL/CentOS because of its popularity on AWS, so we want to prioritize what's next according to demand. 

For example, if you're is using any of these, be sure to let us know:

  • Red Hat Enterprise
  • CoreOS
  • Oracle Linux
  • SUSE (SLES)
  • openSUSE

Ultimately, our goal is that we have a set of Dockerfiles for each of the desired environments, or a centralized set of Linux setup articles. I imagine many will be able to share common configs, but it's important to call out any special considerations (e.g., I recently updated this this KB article => Install libgdiplus library on CentOS and Amazon Linux - Telerik Reporting).

Thank you!

Regards,
Lance | Manager Technical Support
Progress Telerik

Stay tuned by visiting our roadmap and feedback portal pages, enjoy a smooth take-off with our Getting Started resources, or visit the free self-paced technical training at https://learn.telerik.com/.
ADMIN
Ivan Hristov
Posted on: 12 Oct 2023 15:53

Hi again,

Wow, this thread is really on fire! Haven't seen so much buzz for a long time :)

I'll start with the most serious issue reported by @Dmytro Gokun that might affect the users that have referenced Telerik.Reporting in their .NET Core apps as an assembly, rather than a NuGet package.

  • In order to read the embedded assembly resources, we use a ResXResourceReader implementation. This class is not supported in .NET Standard and was not a part of .NET runtime, so we used a NuGet package to obtain this functionality. The name of the package is ResXResourceReader.NetStandard, it uses an MIT license and also has a strong-name variant. This package is added as a dependency in Telerik.Reporting .nuspec file, so if you reference Telerik Reporting as a nuget package, you'll also automatically get the System.Resources.NetStandard.dll assembly. However, if in your project Telerik Reporting is referenced as an assembly, i.e.:

  <ItemGroup>
    <Reference Include="Telerik.Reporting">
      <HintPath>..\..\..\Bin\netstandard2.0\Telerik.Reporting.dll</HintPath>
    </Reference>
  </ItemGroup>

you will get the runtime exception that Dmytro shared below:

Telerik.Reporting.Processing.CancelProcessingException: 'An error occurred while evaluating the report parameters. Report source cannot be processed. Check the InnerException for more information.'

Inner Exception:

FileNotFoundException: Could not load file or assembly 'System.Resources.NetStandard, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

 

The solution is to add a NuGet package reference to https://www.nuget.org/packages/ResXResourceReader.NetStandard in your project, or download its contents, extract it and reference the System.Resources.NetStandard.dll directly.

We are sorry for the inconvenience caused. The bug is logged and will be fixed with high priority, and an explanatory KB will be published shortly. The plan is to try and get rid of this dependency in Telerik Reporting and move it to the modules that require it - Report Designers and viewers.

  • As for the behavior of the reporting engine: if the appsettings.json file is missing, or it does not contain a setting for graphicsEngine, it will behave in a 'PlatformDependent' way: on Windows it will use GDI, and on non-Windows OS: Skia.
  • We haven't tested the Skia implementation on RHEL/CentOS yet, but we've logged it as a task and once we have working Dockerfile, we'll share it here.
  • About the scenario where a desktop viewer (WPF) is connected to a REST Service using Skia on Linux:  yes, currently the REST Service will report only PDF as available rendering extension. We understand that OpenXML formats are widely used, and few of our team members are currently focused on this task: to deliver OpenXML formats for PI1 (Product Increment One), which is scheduled for November 15th. Implementing the missing rendering extensions will remain our main task, along with fixing the currently known issues. The rendering extensions that are not in our focus, are: 1) Image rendering in EMF (Enhanced Metafile) (but you'll be able to render in bitmap formats like BMP, PNG, or JPEG); 2) MHTML rendering extension; 3) XPS rendering extension.

I hope the explanations above were helpful. I would also like to ask you to use the support channel and log a ticket if you've found a bug that needs to be addressed immediately. However, if you can share information that will be useful to the other readers here, we'll appreciate it if you write it in this thread. Me and other team members will monitor this thread and provide further info, if needed.

All best,

Ivan Hristov

Reporting Team

Adam
Posted on: 12 Oct 2023 12:20

 

We are using the REST service with a WPF application viewer.   Is it my understanding that if we migrate the REST service to run in Ubuntu that users will not be able to save off reports in any format other than PDF?   I hope this is not the case as it would be a huge loss in functionality not to be able to save as XLSX, as that has been a minimum expectation of reporting for 30+ years.

If this is the case when can we expect those functions to be added?  You say future release, but does that mean 3 months or 2 years?  

All of our other back-end process have been upgraded with the capability to run in K8S and in order to keep Telerik running we have had to spin up a Windows VM within that K8S environment with massive overhead, so we have eagerly been awaiting this release. We have been using Telerik for many years now and I hope we will be able to move forward with this release with all the functionality our users expect. 

TProSenior
Posted on: 12 Oct 2023 11:44

Have the new methodologies been tested so far on RHEL/CentOS?  If so, what packages are required, etc?

In our installations, we install fontconfig, libgdiplus, and libgdiplus-devel using yum/dnf. In addition, we created a custom rpm for the msttcorefonts2.5.1 that is deployed with the application along with some steps to get those "registered".

What will need to change to account for to take advantage of the new changes on RHEL/CentOS systems (RHEL 8.x/9.x on production, CentOS 9 Stream for development)?

Thank you,
Tim

Dmytro
Posted on: 12 Oct 2023 11:32

Hi Ivan,

okay, so i figured i can just add this snippet to my appsettings.json:

    "telerikReporting": {
        "processing": {
            "graphicsEngine": {
                "engineName": "Gdi"
            }
        }
    }

and gets picked automatically by Telerik. Still i'm getting the same exception (Could not load file or assembly 'System.Resources.NetStandard, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null'.) when specifying 'Gdi'. If i change it to 'Skia' i get another exception (DrawingFactoryUnavailableException: Cannot load assembly Telerik.Drawing.Skia. Make sure it is accessible in the current application domain.). Skia exception is okay and it does not bother me (at least, for now). What i want is to make Gdi work on Windows when using ReportProcessor.RenderReport. Any advice?

Dmytro
Posted on: 12 Oct 2023 10:56

Hi Ivan,

> Currently this scenario is not supported and the switch is only on application level

Well, we actually do no need switching it in the runtime, startup configuration is fine. The problem is that in our service, we do not use any Telerik REST services and stuff. In fact, our service is a simple console app (running on K8S) and the code we have to generate a report is exactly what i have shown you before. Previously, it worked just fine (on Windows). But with this release it has stopped working and we are getting this exception:

Telerik.Reporting.Processing.CancelProcessingException: An error occurred while evaluating the report parameters. Report source cannot be processed. Check the InnerException for more information.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Resources.NetStandard, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
File name: 'System.Resources.NetStandard, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null'
   at Telerik.Reporting.Interfaces.LocalizationContext.InitializeBucket(String resx)
   at Telerik.Reporting.Interfaces.LocalizationContext.GetString(String resx, String key) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Interfaces\LocalizationContext.cs:line 148
   at Telerik.Reporting.Interfaces.StringsResolver.GetString(String key) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Interfaces\StringsResolver.cs:line 22
   at Telerik.Reporting.SR.GetString(String key) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Model\SR.cs:line 17
   at Telerik.Reporting.SRDescriptionAttribute.get_Description() in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Model\SRDescriptionAttribute.cs:line 24
   at Telerik.Reporting.Expressions.EnumContextManager.GetEnumDescription(Type enumType) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Expressions\EnumContextManager.cs:line 61
   at Telerik.Reporting.Expressions.EnumContextManager.GetItem(Type enumType) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Expressions\EnumContextManager.cs:line 17
   at Telerik.Reporting.Processing.ReportExpressionContext.RegisterAllReportingEnums() in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\ReportExpressionContext.cs:line 51
   at Telerik.Reporting.Processing.ReportExpressionContext..ctor(Type reportType, AssemblyRefManager assemblyRefManager) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\ReportExpressionContext.cs:line 21
   at Telerik.Reporting.Processing.ReportParametersManager`1.CreateExpressionContext(Report report, IList`1 runtimeParameters, AssemblyRefManager references) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\ReportParametersManager.cs:line 121
   at Telerik.Reporting.Processing.ReportParametersManager`1..ctor(Report definitionReport, IEnumerable`1 definitionParameters, IDictionary`2 reportSourceParameters, IDataProviderContext dataProviderContext, AssemblyRefManager references) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\ReportParametersManager.cs:line 105
   at Telerik.Reporting.Processing.ReportParametersManager`1..ctor(Report definitionReport, IDictionary`2 reportSourceParameters, IDataProviderContext dataProviderContext, AssemblyRefManager references) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\ReportParametersManager.cs:line 81
   at Telerik.Reporting.Processing.DocumentParametersManager`1.CreateManager(Report definition, IDataProviderContext dataProviderContext, IParameterValueParser parameterValueParser, IDictionary`2 rsParameters, AssemblyRefManager references) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\DocumentParametersManager.cs:line 235
   at Telerik.Reporting.Processing.DocumentParametersManager`1.CreateManagers(IProcessingContext context, IParameterValueParser parameterValueParser) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing\DocumentParametersManager.cs:line 183
   at Telerik.Reporting.Processing.ReportProcessor.ProcessReportSource(ReportSource reportSource, IRenderingContext context) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.ProcessReport.cs:line 227
   --- End of inner exception stack trace ---
   at Telerik.Reporting.Processing.ReportProcessor.ProcessReportSource(ReportSource reportSource, IRenderingContext context) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.ProcessReport.cs:line 234
   at Telerik.Reporting.Processing.ReportProcessor.ProcessReportSource(ReportSource reportSource, Hashtable deviceInfo, IRenderingContext context) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.ProcessReport.cs:line 153
   at Telerik.Reporting.Processing.ReportProcessor.ProcessAndRender(String format, ReportSource reportSource, Hashtable deviceInfo, IRenderingContext renderingContext, CreateStream createStreamCallback) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 468
   at Telerik.Reporting.Processing.ReportProcessor.ProcessAndRenderStateless(String format, ReportSource reportSource, Hashtable deviceInfo, IRenderingContext renderingContext, CreateStream createStreamCallback) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 439
   at Telerik.Reporting.Processing.ReportProcessor.<>c__DisplayClass47_0.<RenderReport>b__0(SingleStreamManager sm) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 108
   at Telerik.Reporting.Processing.ReportProcessor.RenderReportSafe(Func`2 renderCallback, String format, IRenderingContext renderingContext) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 216
   at Telerik.Reporting.Processing.ReportProcessor.RenderReport(String format, ReportSource reportSource, Hashtable deviceInfo, CancellationToken cancellationToken) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 107
   at Telerik.Reporting.Processing.ReportProcessor.RenderReport(String format, ReportSource reportSource, Hashtable deviceInfo) in D:\a\reporting\reporting\reporting\Source\Code\Telerik.Reporting\Processing.ReportProcessor\ReportProcessor.RenderReport.cs:line 87

 

This assembly, System.Resources.NetStandard, does not even exists on Windows. So, my hypothesis is that with this new Telerik Reporting version, by default it attempts to use a Skia engine. We do not really want to do that at the moment (we plan our Linux transition for some time later). Only thing we need is to make this code work again with this new version. For that, we somehow need to tell it which engine to use. How do we do that w/o using Telerik REST Services?

ADMIN
Ivan Hristov
Posted on: 12 Oct 2023 09:07

Hi all,

We're happy that you have already managed to test the newest bits and they even work :). Now up to your questions:

"... any idea what the equivalent font lib would be for Alpine linux?"

We haven't tested Alpine distro, but you can try adding the  SkiaSharp.NativeAssets.Linux.NoDepedencies packageReference that contains the full set of Skia-needed libs. AFAIK there's also a NuGet package dedicated for Alpine: StoneCold.SkiaSharp.NativeAssets.AlpineLinux. This SO thread describes a successful Docker deployment of Skia on Alpine and might help.

"how do we switch the graphics engine when using ReportProcessor directly?"

Currently this scenario is not supported and the switch is only on application level (through the configuration file). There are internal methods that support runtime switching of graphics engine, and they can be used through reflection, but this approach is not recommended for public use. For performance reasons we initialize static fields and other singleton instances with logic, specific to the current graphics engine (like StringFormat, generic font families, font providers, etc.) and they all need to be invalidated and re-initialized when switching the graphics engine, which comes at performance cost. However, we may be missing something, so I'd like to ask you to elaborate further and share what business scenario could require switching the engines at runtime - except for development purposes, of course.

Thank you for your input!

Ivan Hristov

Reporting Team

Dmytro
Posted on: 12 Oct 2023 07:40

Thanks for the much anticipated release.

Question: how do we switch the graphics engine when using ReportProcessor directly, like this:

        var reportSource = new InstanceReportSource { ReportDocument = document };
        var deviceInfo = new Hashtable();
        var result = new ReportProcessor().RenderReport("pdf", reportSource, deviceInfo);

?

Rodney Moore
Posted on: 11 Oct 2023 19:51

not sure i can give you a pass since this has been a question since 2021 

you really dropped the ball here

Thomas
Posted on: 11 Oct 2023 19:27
Ivan:
Thanks for the update it is much appreciated.  I've got the reporting engine running on a Mac M2 machine now and everything seems to be working well.  One question though, any idea what the equivalent font lib would be for Alpine linux?
Sam
Posted on: 11 Oct 2023 14:18
I know what amount of work is involved with this, great job Reporting Team!
ADMIN
Ivan Hristov
Posted on: 11 Oct 2023 09:57

Hi all,

We just published our 2023 R3 release and Skia-enabled rendering is part of it - as promised. Here's a short muted video that shows how to run our HTML viewer in WSL using Ubuntu 22.04.

The video demonstrates how to set the graphics engine in the appsettings.json file and how to add the necessary Nuget package Telerik.Drawing.Skia.nupkg.

What's not seen in the video is the additional configuration of the Ubuntu distro, which includes installing the graphics modules (which I did it with 'apt-get install -y libfontconfig1'), and installing the set of Microsoft fonts used in the reports (which I didn't do).

Currently supported rendering formats are HTML5 Interactive, HTML5 PrintPreview, and PDF. The rest of the rendering formats (DOCX, XLSX, etc.) will be added in the following releases of our product.

Replacing the graphics engine in Telerik Reporting with a brand new implementation is a huge feat for our team and we'll appreciate it if you give it a try and share your thoughts.

All best,

Ivan Hristov

Reporting Team

Attached Files:
Rodney Moore
Posted on: 13 Sep 2023 12:54

we just need it done not screenshots begging for  forgivness.

this stopped me buying your blazor components cause i cant trust your company will keep current  

 

ADMIN
Ivan Hristov
Posted on: 13 Sep 2023 12:25

Hello all,

I can assure you I understand your concerns about the current state of Linux support in Telerik Reporting. I can also assure you that the major part of our dev force works on this task with one goal in mind - to deliver HTML and PDF rendering using Skia in 2023 R3 release.

Dan Flanigan is completely right - we knew and we should have been prepared. That's why it makes no sense to get into details about the task complexity or the amount of changes that need to be done. Instead, I will share one recent image from our work in progress - it's the well-known Dashboard report, rendered in PDF using our SkiaSharp implementation.

It's easy to see it's far from perfect - there are text misalignments, the graphic paths are not exactly the same as before, some positions are miscalculated... but I hope it gives you confidence that we're dedicated to deliver the promised functionality.

As we advance further, I will be more than happy to share our progress here, so stay tuned!

 

Ivan Hristov,

Reporting Team

Dan
Posted on: 07 Sep 2023 14:42

We are creating infrastructure just for running Telerik reporting in .NET 6 / Debian outside of our primary web application running containerized on .NET 7.

 

This entire situation has left a terrible taste in my mouth - you guys knew and should have been prepared for this. We will be considering slowly moving to ActiveReports when our new application goes live. We shouldn't have to search for a glorified blog post -- this should have been front and center within the release notes.

EDUARDO ALEJANDRO
Posted on: 11 Aug 2023 20:55

Thank you, Ivan.

 

We've been a Telerik customer for years, and we've been waiting for this fix for a very long time. This is seriously damaging our products since we cannot implement newer, better versions of .NET because of this problem. Our hearts will be broken if this doesn't come out in R3 this year.

Fingers crossed, I hope the best for your team so they can finally implement this and be ready for .NET 8.

ADMIN
Ivan Hristov
Posted on: 21 Jul 2023 08:59

Hi all,

Yes, we are working on the task with highest priority for our R3 release. As explained earlier, in R2 the engine still uses GDI+, but the abstraction part is done and is being used as a base for Skia implementation. We believe that for R3 we will implement all the necessary logic for correct measurement and rendering, focusing initially on HTML and PDF rendering extensions.

Regards,

Ivan Hristov

Telerik Reporting

Thomas
Posted on: 18 Jul 2023 20:02

I just wanted to check in and see what the status of this is moving towards 20203.R3.  Are we on schedule for linux support in 2023.R3?  Below is what we were told would be in place for 2023.R2:

"For R2 we will implement an abstraction of the graphics layer to a set of interfaces, but the engine still will be using the GDI+ implementation. This abstraction is mandatory so we can plug the Skia implementation and use it instead of the GDI+ calls."

ADMIN
Dimitar
Posted on: 20 Jun 2023 12:31

Hello,

Thank you for the feedback!

@Hans

As you have already discussed with my colleague Momchil in a separate ticket, the only two approaches left at the current time are to either:

  • Uninstall the new runtime (7.0.7) and re-install the previous version (7.0.5).
  • Use Parallels to set up a Windows VM where the issue should not be present

@dsfsdf

We have mentioned the problem in the Using Telerik Reporting with .NET Core, 6, 7, or Standard - Telerik Reporting article which is the main article to go to regarding our product's .NET Core features and limitations.

Regards,
Dimitar
Progress Telerik

Stay tuned by visiting our roadmap and feedback portal pages, enjoy a smooth take-off with our Getting Started resources, or visit the free self-paced technical training at https://learn.telerik.com/.
Hans
Posted on: 15 Jun 2023 08:45

This needs to be fixed as soon as possible. The Telerik.Reporting for ASP.NET Core worked until version 7.0.5. When updating to version 7.0.7 the System.Drawing library used through Telerik.Reporting throws the following error:

"InnerException {System.TypeInitializationException: The type initializer for 'Gdip' threw an exception.  ---> System.PlatformNotSupportedException: System.Drawing.Common is not supported on non-Windows platforms. See https://aka.ms/systemdrawingnonwindows for more information.    at System.Drawing.LibraryResolver.EnsureRegistered()    at System.Drawing.SafeNativeMethods.Gdip.PlatformInitialize()    at System.Drawing.SafeNativeMethods.Gdip..cctor()    --- End of inner exception stack trace ---    at System.Drawing.SafeNativeMethods.Gdip.GdipCreateBitmapFromScan0(Int32 width, Int32 height, Int32 stride, Int32 format, IntPtr scan0, IntPtr& bitmap)    at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)    at System.Drawing.Bitmap..ctor(Int32 width, Int32 height)    at Telerik.Reporting.Drawing.Unit.GetDotsPerInch()    at Telerik.Reporting.Drawing.Unit.ResetDpiSettings()    at Telerik.Reporting.Drawing.Unit..cctor()} System.TypeInitializationException"

"System.Drawing.Common is not supported on non-Windows platforms. See https://aka.ms/systemdrawingnonwindows for more information."

Until version 7.0.7 of .NET Core I was able to work around this issue using a third party Nuget package:
https://github.com/curiosity-ai/libgdiplus-packaging

Could you please address this issue as soon as possible?

With regards,
Hans Sixhöj
A Perfect Day AB
https://www.billingpoint.se

dsfsdf
Posted on: 14 Jun 2023 08:58

I spent three hours of my day trying to follow all your outdated documents only to stumble across this.

You really need to make sure this is spelled out on your pages, and while you are there, clean up all the outdated ones.

 

 

ADMIN
Dimitar
Posted on: 02 May 2023 09:02

Hi Giancarlo,

In regard to the first question, whether this problem will be present in future .NET versions, once we migrate from GDI+, the problem should be resolved for the current and future .NET versions included.

The only reason it currently works in .NET 6 but not in .NET 7 is due to Microsoft choosing to leave out a switch for using the System.Drawing.Common namespace in the older .NET. but removing it starting with .NET 7.

Regarding the second question, yes, we still intend to implement this for the R3 release later this year, please stay tuned.

Thank you for using Telerik Reporting!

Regards,
Dimitar
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/.
Giancarlo
Posted on: 28 Apr 2023 21:22

Hello Dimitar,

May I trouble you please with responses to my 2 below questions? My team is trying to make a decision whether we should move to .NET 6 or .NET 7, and it all hangs on this issue with Telerik Reporting.

Thanks again for your help

Giancarlo
Posted on: 26 Apr 2023 12:50

Hello Dimitar,

Now that Skia will or can be used instead of GDI, is it fair to say that going forward we won't run into this same issue with new versions of .NET (e.g. .NET 8)? I ask because it was a curveball that it works on .NET 6 but not .NET 7.

And also, can you please confirm (or deny) that things are on track still for having this fix for R3 2023?

Thank you

ADMIN
Dimitar
Posted on: 26 Apr 2023 11:05

Hello Giancarlo,

R3 releases are usually in September but this year it might come out a little later, October is more likely at this point.

You may see when the R3 releases come out usually at the Telerik Reporting Release History page.

Regards,
Dimitar
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/.
Giancarlo
Posted on: 25 Apr 2023 15:20

Hello Dimitar,

Approximately when will R3 2023 be released?

Thank you

ADMIN
Dimitar
Posted on: 13 Apr 2023 12:14

Hello Oleg,

Yes, we do plan to support .NET 7+ on non-Windows-based operating systems in the future.

We are working on it and our intentions are to deliver this feature with the R3 2023 release later this year, please stay tuned.

Regards,
Dimitar
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/.
Oleg
Posted on: 07 Apr 2023 19:42

Hello, guys!

Could you please tell me if you currently have any plans in the roadmap to support Telerik Reporting for .NET 7 / .NET 8 on Linux? Are you already working in this direction?

Our solution is stuck on .NET 6 (Linux) because of the dependency on Telerik Reporting components and I would like to understand whether we should just wait for some near future or come up with some alternatives to bypass these dependencies.

ADMIN
Ivan Hristov
Posted on: 28 Feb 2023 21:45

Hello Thomas,

I can assure you that we do not underestimate the significance of this feature and fully understand how important it is. We realize that replacing the current graphics library with Skia will also resolve the problems that we currently have not only on Linux, but also on Azure, where most of the GDI+ calls are getting gradually blocked. Enabling the usage of an alternate graphics library will allow us to label our product as truly cross-platform.

This is our top priority feature along with the Visual Studio Report Designer for .NET projects and - as always - we will keep you updated on our progress.

All best,

Ivan Hristov

Thomas
Posted on: 21 Feb 2023 22:36

Ivan:
Thank you for clarifying.  I'm not getting the felling this is getting the attention it deserves.  This issue has prevented us from upgrading to dotnet 7 and based on your timeline will cause us to miss the entire dotnet 7 release.  I can see missing the original release of dotnet 7 by a few months but this is a year late! 

Think about that, there is no support for dotnet 7 on Linux for Telerik Reporting and by the time support is released dotnet 8 will be out.  

ADMIN
Ivan Hristov
Posted on: 13 Feb 2023 16:13

Hi Thomas,

Sorry if my post was confusing.

For R2 we will implement an abstraction of the graphics layer to a set of interfaces, but the engine still will be using the GDI+ implementation. This abstraction is mandatory so we can plug the Skia implementation and use it instead of the GDI+ calls.

In short: 2023 R2 will still be using GDI+ as a graphics library. 2023 R3 will enable the functionality to switch between GDI+ and Skia.

I hope I managed to explain it better this time :)

All best,

Ivan Hristov

Thomas
Posted on: 13 Feb 2023 14:01
Ivan:
Thanks for the additional information, can you clarify your statement for us?  Will we be able to swap out the engine GDI+ for Skia with the R2 2023 release?  That's what it sounded like you were saying but then you said everything should work in R3.
ADMIN
Ivan Hristov
Posted on: 13 Feb 2023 13:49

Hi Dominik,

Thank you for notifying us about the incorrect status of the feedback item - I have just updated it.

I can assure you that the adoption of Skia library in our product is regarded as a feature with highest priority.

For R2 2023 we plan to refactor the graphics-dependent code to support pluggable architecture, so the users could easily switch between GDI+  and Skia rendering, even on Windows machines where GDI+ is natively supported. The effort will continue in the following months, and we believe we will be able to deliver a working solution for our R3 2023 release.

All best,

Ivan Hristov

Dominik
Posted on: 05 Feb 2023 16:39

Hi,

any new decisions you can share with us yet? This is currently holding us back from moving to NET7 as well.
This is getting harder for me to defend especially because this here is the only issue about it and it is still marked as "Unplanned".

NET8 might still be months away, but I imagine moving to a different rendering library is a months long endeavor to get right as well.
So any (technical) news or any alpha version to test would be very appreciated.

ADMIN
Dimitar
Posted on: 16 Jan 2023 14:22

Hello,

Indeed, support for System.Drawing.Common has been dropped for non-Windows environments starting with .NET 7 - Breaking change: System.Drawing.Common only supported on Windows - .NET | Microsoft Learn.

We are aware of this limitation and it is in our plans for the 2023 year to switch to another graphics library, however, that will not happen for the R1 2023 release coming out in the next few days. We are putting our efforts into implementing this for R2/R3 2023 and will update the thread as soon as we have confirmed a release date.

We appreciate your patience!

Regards,
Dimitar
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/.
Thomas
Posted on: 09 Jan 2023 20:24

@Dimitar that is true IF you are using Telerik Reporting with .Net 6 as your example shows, however if you are using Linux and .Net 7 your example fails to load.

 

@Milen any update on .Net 7 and Linux support for Telerik reporting are you still planning on May of 2023?

Ado
Posted on: 16 Dec 2022 09:01

@Sam, I know it's not LTS but this doesn't mean that is not ready for production, its support ends in May 2024. Our plan was to move to .net 7 this year and to .Net 8 in Dec 2023.

Furthermore, .net7 runtime is much faster in some areas and it has a lot of new features that we want to adopt for current and new versions of our system we planned for January.

Ado

 

 

 

Sam Morreel
Posted on: 16 Dec 2022 01:06

@Ado,

Have you considered that .NET 7 is NOT long term service and .NET 6 is? Is skipping .NET 7 until a new LTS version comes a possibility for you?

Cheers.

Ado
Posted on: 16 Dec 2022 00:52

I'm discovering now that we can't move our system on k8s to .net7 because Telerik reporting is not working on Linux.

I know that it maybe be challenging to swap the GDI library with SkiaSharp but it should have been planned ahead of time as GDI+ itself is a really ancient graphics library with a lot of issues.

We planned to move from .net6 to .net7 before the end of the year, a big system with a lot of microservices and many people involved: a lot of work is wasted now.

As a long Telerik customer, I feel that I must have been informed with a direct email, even more than one email, ensuring that all of us (your customers) were clearly aware of such a giant issue.

Sorry for the complaint,

Adolfo Marinucci

 

 

ADMIN
Dimitar
Posted on: 11 Nov 2022 15:30

Hello,

For those that use Docker to deploy their application that uses Telerik Reporting, there shouldn't be any issues as long as the required Telerik Reporting dependencies installation is part of the Dockerfile.

As an example setup, please have a look at the following Dockerfile DevOpsExamples/Dockerfile at 2faa76e574902088fb7a2bae8396d24f7b81bdcc · LanceMcCarthy/DevOpsExamples (github.com).

To quickly test this, you may run the following command:

docker run -d --name="TelerikReportingTest" -p 880:80 lancemccarthy/myaspnetcoreapp:latest

Then open localhost:880 and go to the ReportViewer page. We hope this helps!

Regards,
Dimitar
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/.
Ryan
Posted on: 04 Nov 2022 23:53
We deploy our apps to Azure App Service for Linux.  We will likely ignore .NET 7, since Microsoft won't give it Long Term Support (LTS).  However, we will very likely adopt the next following (LTS) version after .NET 7.
Thomas
Posted on: 28 Sep 2022 11:58

Milen:
We deploy our application to Linux via docker.  Right now our base image is Ubuntu. 

Actual Image: mcr.microsoft.com/dotnet/aspnet:6.0-focal.

We tried alpine a few times with little luck due to dependencies for Telerik Reporting, so that is another one we would be very interested in.  With Azure AKS now supporting ARM that is another area of interest for our runtime.

ADMIN
Milen | Product Manager @DX
Posted on: 28 Sep 2022 09:09

Hello Thomas,

Thank you for your care. Mid-May 2023 continues to be our target for this feature. I will share here anything meaningful I have.

Thomas, It would help if you describe the exact platform you guys deploy on. Thank you!

Regards,
Milen
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/.
Thomas
Posted on: 15 Sep 2022 14:41
Milen, would it be possible for you share updates on a regular basis?  This will help us also plan for our .Net 7 upgrade alongside yours.
ADMIN
Milen | Product Manager @DX
Posted on: 21 Jul 2022 11:18

All,

Indeed, the fact that .NET 7 completely shuts down System.Drawing on non-Windows platforms puts us in a very hard situation. We have already started the research and it seems we will need to make a big architectural change in the product in order to integrate and use another drawing library. Most probably, we will go with SkiaSharp. As a time frame, I cannot promise we will be done along with the official .NET 7 release. Realistically we will target the R2 2023 release scheduled for May 2023. I will update you here when I have more details to share.

Meantime, any ideas are more than welcome. Thank you for your engagement.

Regards,
Milen
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/.
Christopher
Posted on: 13 Jul 2022 15:01

i am running the reporting code in a Linux container also.

We pass Telerik images for our reports and lack of System.Drawing.Common is going to break this in .Net 6 and going to be dead broke in .Net 7

For those unaware.. you can add this into your runtimeconfig.template.json to get Systme.Drawing.Commin working on .Net 6

    "configProperties": 
    {
      "System.Drawing.EnableUnixSupport": true
    }

This workaround will go away in .Net 7

We absolutely must have the ability to print images using Telerik Linux containers.

I can imagine this is a nightmare for the Progress Architects.

However, from a business standpoint this has to be in the product for us to continue using it.

As this is your dependency, I am not concerned with how you implement it.

 

 

 

 

 

Sean
Posted on: 24 Jun 2022 20:08

We run all our applications in custom Linux containers on AWS just to support your reporting libraries.

This will be vital to be able to go to .NET 7.

 

 

 

 

Sam Morreel
Posted on: 14 Apr 2022 00:25

Chiming in here,

Please see for reference -> https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only

Currently, we use Telerik reporting extensively on Linux. We recently upgraded several nuget packages that caused System.Drawing.Common to be updated to file version 6.x.x. According to the article above, in order to continue to use System.Drawing.Common under .NET 6 on Linux, we needed to add a runtime switch. This did indeed fix the exception.

However, this switch is gone in .NET 7.0. Microsoft's recommendation is to use:

It's likely that Maui.Graphics is the strategic choice, given its ability as a complete cross platform library. My vote would be for Maui as a replacement, but I'll take anything as long as we can continue to use Telerik reporting on .NET 7.0.

Cheers,
Sam.

 

ADMIN
Dimitar
Posted on: 02 Feb 2022 07:10

Hello Tursunkhuja,

Telerik Reporting is constantly making improvements on the rendering behavior under Linux, however, migrating to the SkiaSharp library is not in our roadmap for 2022.

Regards,
Dimitar
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/.
Tursunkhuja
Posted on: 26 Jan 2022 08:09

Hi All,

We also have similar problem. Our project based on .net6 and we are planning to use reporting in Linux environment.

When you are planning to improve Telerik Reporting rendering behavior on Linux machines? or when you expecting to use SkiaSharp library.

 

Thank you,

Gregory
Posted on: 24 Nov 2021 14:40
we will renew our license if you will do it
ADMIN
Dimitar
Posted on: 25 Oct 2021 14:20

Hello Levi,

Thank you for the valuable feedback!

I just want to mention that it is possible to run Telerik Reporting on Linux even today but the library libgdiplus is required. This library is a Mono implementation of GDI+ API for non-Windows operating systems - Using Telerik Reporting in Applications on Linux Platform.

Regards,
Dimitar
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/.
Levi
Posted on: 18 Oct 2021 20:19

Thanks for the update. This is one I'm keenly interested in.

For reference, my use-case is with Azure Functions. Being able to host in Linux would enable us to adjust our hosting tier to much higher performance for the same cost (currently on Windows hosted). Although when I think about again, being able to fully drop the GDI dependency would also let us move to the dynamic serverless tier (which blocks most GDI access).

I understand that it's a large change and you can't give a commitment or timeline, but this feature would be huge for us - the further ability to run Telerik reports easily in more environments.

ADMIN
Dimitar
Posted on: 06 Oct 2021 12:53

Hello Levi,

Thank you for raising awareness of those potential issues.

Our long-term plan is to try and refactor our drawing logic to utilize the SkiaSharp library.

Even if MS does not drop the support for System.Drawing.Common, the currently used library, libgdiplus, has multiple issues with text measuring, clipping, working with units other than pixels, etc. and we are researching for a solution to improve the Telerik Reporting rendering behavior on Linux machines. The SkiaSharp library may be the answer to those problems.

Please let us know if you have any other questions.

Regards,
Dimitar
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/.
Create an account Log In
View
Type
Status