Thinking of Page Support?

Mar 15, 2013 at 9:48 AM
Thus HTML Renderer can be a report viewer or something.

List<Page> pages = HTMLRenderer.Render(Graphics graphics, Size PageSize);
Developer
Mar 17, 2013 at 10:00 AM
Can you elaborate on the feature.
Is it part of html/css spec?
Dec 26, 2013 at 8:35 AM
I think I understand what is meant here, as I was going to request what I think is the same. As the original author did not seem to elaborate, allow me to do so (I'm from a Delphi community and I'm not familiar with .NET so some technical terms may be wrong here).

I was considering using HTML Renderer to render HTML text on a print preview that can span several pages of paper. What can happen is that the rendering reaches the end of page 1 and needs to resume where it left of on page 2. As far as I can tell, the rendering cannot change graphic in the middle of a rendering. Therefore, if your HTML text is too big to fit on 1 page, part of the HTML document is not rendered (what is past the bottom of page 1 and should be drawn on top of page 2). What could be useful is when the rendering reaches the end of the rendering rect, to allows the graphic to be changed (the hdc of page 2), the rendering rect to be changed and have the layout recalculated for all the elements that are yet to be drawn.

In pseudo-code:

PageIndex = 1;
Parse HTML document
While Not Rendering.Done
{
Create Page(PageIndex)
Get Graphic and rendering rect for that page
Recalculate Layout (of elements not yet drawn)
Render HTML on page
PageIndex += 1
}
Developer
Jan 6, 2014 at 1:24 PM
I see, thanks for the details.

This can be done using HtmlContainer.ScrollOffset property.
Lets say the page height is 1000px then when you want to render page 2 you set ScrollOffset to -1000 (note the negative value):
ScrollOffset = new Point(0,-1000);
-2000 for page 3, etc...

Note 1: you will need to have to do manual work to create the HtmlContainer, set MaxSize restriction by the page size, call PerformLayout and call PerformPaint once for each page.

Note 2: this approach has a significant drawback, if the "page" ends in a middle of a text line it will cut between the end of page 1 and the beginning of page 2.
Having proper support for it will require to ignore text rendering when it is outside of vertical restriction which can be complicated for complex layouts..

Note 3: because you wan't to render to print device you should use GDI+ text rendering for better results.
UseGdiPlusTextRendering = true;
Feb 26, 2014 at 3:53 PM
I'd definately like to weigh in on this topic as it's the very reason I was out looking for a rendering api.

I process DICOM data discs from various development companies which handle reporting in numerous ways. The vast majority of the reports are in html and are multiple pages long. Basically a bunch of 8.5x11 sheets chained together. What I end up doing is printing them to PDF then using Ghostscript to output as individual JPG pages for processing.

Though this API looks very promising there is a lot of need for it to be able to simply output a series of files as described by tetardd above which would make it much more productive and easier for handling numerous reporting conversions. Now days MS Word can output a whole multi-page report as html so this is becomming much more common. Rendering PDF would also be a huge plus. If it's in decent shape and stable I don't have any problems paying for this tool if it will save me some time and simplify my process.

Something along the lines of :
Image[] image = HtmlRender.RenderToImage(strText, new Size(816, 1056), new Size(816, 1056), new Color(), null, null, null);
Developer
Feb 27, 2014 at 8:17 AM
I see this kind of scenario more and more so I will do the work for v1.5
I'm planning on supporting PDF pages rendering using PdfSharp project.
Adding similar page rendering support to images should not be too complicated after the PDF work is done.
The API will probably look very similar to what you have in mind.

I wish I could give you a time-frame on that but my full-time work keeps me busy.
Feb 27, 2014 at 8:38 PM
I'd worry more about getting the core of this rendering 100% first. I threw a bunch of pages at it and there were some formatting issues. It also didn't handle when the css was in the page already as <style> tags which is very problematic as I have no control over how the pages are formatted when I get them. You can test just by saving a few pages to html with word. I can also pass you a couple of report pages I got that didn't format well that were vanilla text if you wish. Getting a rendering API solid that doesn't rely on the webbrowser control is something a lot of folks are looking for, figuring we'll be gaining a performance boost. Right now I'm having to use a function I wrote to automate the webbrowser control and output to JPG directly. Renders great as I would expect, performance is a bit less than I'd like though. Keep the PdfSharp as a plug-in library over complile in with dependencies as some folks just won't be interested in it.

If you want to do the PDF wrapper your self I have a cheap PDF wrapper class I wrote for an archive project here that will take any image and create a pdf out of it that you can have or use as basis to understand it. Not hard to do. Coding isn't all that as it was just a quick prototype but it will give you and idea of how it works.

I have this tagged as a promising product and will be keeping an eye on this. I completely understand about work load, I have enough projects piled up for me to complete here to literally keep me busy for the rest of breathing days.

We're all just killing time until it kills us.
Developer
Mar 2, 2014 at 8:20 AM
Rendering 100% is extremely complicated and may takes months to do, I don't think it's the best investment at this point.
In the long run I'm planning to do a major redesign of the library so I will be able to add support for complex layout, in the short run when I come across issues that can be relatively easy to fix I do fix them.
So if you can post examples of badly rendered HTML I may fix some of them in the coming versions.

Regarding the <style> tag on the page, it is fully supported so please post the html so I can fix the specific bug there.

The plan is to support real PDF rendering, not using image, that you can do right now.

Thx, I'm very proud of the project.