Hello

I have a problem with report generating. We use HTML5 report viewer and basic implementation of ReportsControllerBase on server.
I've noticed that we have the CPU/memory recourse consumption after immediately pressing Stop Rendering button. The time of consumption recourses is the same as time without cancelling(about 18-20 second in my example)
There is log with calls of report generating. Last one with cancelling, previous without. 
(see
*** ReportProcessor.ProcessReport DONE in 00:00:16.1918150 ***
and
*** ReportProcessor.ProcessReport DONE in 00:00:16.8522950 ***)

I've investigated how cancelation is working.
The Stop Rendering button send DELETE request to ReportsControllerBase.DeleteReport endpoint. It does something and set IsDeleted flag for document.
Then DocumentCancellationController.ThrowIfCancellationRequested() is called in some specific places in app. You can see that method in log.txt, so it was called after pushing the button.

I've profiled the hot path of generation of report. See hotpath.png.
The most CPU intensive work happens in ReportProcessor.ProcessRepourtSource()...
Pay attention to rendering calls.png - the first red dot here - ReportProcessor.ProcessRepourtSource() call.
The second - where the exception and actual cancelation happens.
I'm expecting it should happen much earlier and cancellation of generation of document(and resources consumption) will finish ASAP.

By the way, I see some cancelation checks in ReportProcessor.ProcessRepourtSource() as well - see throwIfCancellation.png
But cancelation request came after these check and most intensive CPU works already started.


Is it possible to fix that?

Due to breaking changes related to the Kendo state classes - https://docs.telerik.com/aspnet-core/styles-and-layout/components-rendering-overview#state-classes, report parameters loaded in the HTML5 Report Viewers that use the ListView widget, are not selected properly, thus the report is not updated with a new report source and the data does not change.

Ideally, if the user prints a report, the output should be the same as what they see on the screen.

Currently, if the user prints/exports the report sometime after previewing it, the data will be updated and they will not get what they see.

Currently, the WinUI ReportViewer has a hard dependency on Windows due to the fact that the internals rely on the Win32 print dialog.

This means I cannot define the ReportViewer in a WinUI class library to be shared with multiple front-end WinUI projects. If you attempt to do this, there's an internal crash because the project cannot resolve  System.Windows.Forms.

This feature request is ask if you can replace the Win32 print dialog with the WinRT printing API. 

Research Note:  Here's a GitHub thread where Microsoft is discussing the topic Question: Printing in WinUI 3 Desktop · Issue #4419 · microsoft/microsoft-ui-xaml (github.com). Here's their current recommendation:

var hWnd = WinRT.Interop.WindowNative.GetWindowHandle(App.StartupWindow);
var printMan = PrintManagerInterop.GetForWindow(hWnd);

await PrintManagerInterop.ShowPrintUIForWindowAsync(hWnd)

If I put the following content in an HtmlTextBox, when I open the preview mode of the designer or look at it in the Html5 Report Viewer I get annoying extra gaps:

<p>Comment</p><p>Comment</p><ol><li>List</li><li>List</li><li>List</li></ol><p><br></p><p>Comment</p><p>Comment</p>

I tried to replace these <p>-tags with <div>-tags:

<div>Comment</div><div>Comment</div><ol><li>List</li><li>List</li><li>List</li></ol><div><br></div><div>Comment</div><div>Comment</div>

It helps. But there are some other tags that cannot be replaced (tags of ordered and unordered lists for example). And these gaps are still rendered. 

When exporting the tags for the document's Table of Contents Telerik Report Designer exports TOC leaders as distinct tags, requiring that they be removed when completing the accessibility tagging for the document. Leaders - the ellipses found in the Table of Contents (e.g., Introduction ...................... Page 3) between the TOC item and the page number will be read by assistive technology as "dot dot dot dot dot..." etc. They need to be deleted from the tag tree. Please Artifact them or (preferably) NOT tag them on the export. Thanks.

Reference: 

https://www.levelaccess.com/pdf-table-of-contents/

https://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/pdf.html 

When exporting to PDF from Telerik Report Designer the software creates a list of flat links for each TOC entry, but the links are separated in the structure from the TOC Label. While a good start, it would be better to use a main TOC tag under which each line in the TOC would receive a TOCI (Table of Contents Item) tag. Each TOCI would contain the label and link for the respective item. Attaching a few examples to assist.

References:

https://www.hhs.gov/sites/default/files/pdf-tagging.pdf (page 29).

https://www.pdflib.com/pdf-knowledge-base/pdfua/the-pdfua-standard/ 

Using the Default or Material Kendo Theme (v5.6.0) with the Telerik HTML5 Report Viewer, the Boolean parameter which uses a Checkbox for it's display, is not visible (this may affect other themes as well).

I confirmed an older version v4.40.0 has a height and width set for the k-checkbox CSS class as such:

https://unpkg.com/@progress/kendo-theme-material@4.40.0/dist/all.css

.k-checkbox {
    border-radius: 2px;
    margin: 0;
    padding: 0;
    width: 16px;
    height: 16px;
    line-height: initial;
    border-width: 2px;
    border-style: solid;
    outline: 0;
    box-sizing: border-box;
    background-position: center;
    background-repeat: no-repeat;
    background-size: contain;
    display: inline-block;
    vertical-align: middle;
    position: relative;
    cursor: pointer;
    -webkit-appearance: none;
}

while the latest v5.6.0 does not:

https://unpkg.com/@progress/kendo-theme-material@5.6.0/dist/all.css

.k-checkbox {
    margin: 0;
    padding: 0;
    line-height: initial;
    border-width: 2px;
    border-style: solid;
    outline: 0;
    background-position: center;
    background-repeat: no-repeat;
    background-size: contain;
    display: inline-block;
    flex: none;
    vertical-align: middle;
    position: relative;
    cursor: pointer;
    -webkit-appearance: none;
}

The checkbox is actually on the page, but is so small it's basically invisible and completely unusable, requiring a manual CSS override to fix.

Steps to reproduce the problem:

Hi, While the Report Designer exports tags to the PDF (with Accessibility enabled), the tags exported are not fully compliant with PDF/UA or 508 requirements. For example, my document has several hundred pages, each with two or three data tables on them. While the tags get exported, they are only Paragraph tags, and NOT Table tags. Is there a way to designate Table Header Rows, Header Columns, and Data Cells in Telerik Reporting such that upon export to PDF they get tagged properly?

Currently,  you can select multiple report items with the CTRL when you run the Web Report Designer on Mac, however, this is interpreted as a right-click. Please, check the attached video.

The correct behavior should be by using CMD.