A lot of things has changed in the past year and it seems more is going to change in the next, unfortunately those changes are not aligned with the work required for HTML Renderer. That's why it took so long for v1.5 release to finally be ready and the reason not all features I originally planned made it.
With a heavy heart I'm going to hold all significant work on HTML Renderer until either my career path brings me back to .NET, I have more free time to work on it or the project will get more attentions. In the meanwhile I will continue to support the library with small fixes and answering question on the discussions/issues pages.
The requirement to generate image from HTML snippet appears to be quite popular, as seen in a few StackOverflow questions1, so I have decided to properly support it in HTML Renderer to simplify the process and improve the results.
The support for image generation in HTML Renderer existed since day one, but it required manual handling of image graphics object, size limitations and configuration toggles.
Additionally the change to use GDI text rendering in 22.214.171.124 broke2 the most common code used for generating image with HTML Renderer, as provided in several blogs and StackOverflow answers3.
That's a long title that perfectly captures another issue I have found with GDI+ text rendering.
While checking Kris's claim on text rendering using GraphicsPath1 I have noticed that GDI+ text rendering using TextRenderingHint.AntiAlias looks much better (less fuzzy) in simple tests than the result of using HTML Renderer to generate transparent image (using AntiAlias hint). It's strange as HTML Renderer uses the same GDI+ text rendering method.
The saga of GDI text rendering issues continues, after solving Transparent text rendering with GDI I got a complain that using HTML Renderer to rendering images (PNG, bitmap, etc.) results in pixelated text as discussed in this HTML Renderer discussion.
After changing HTML Renderer to GDI text rendering (see previous post and this one) I have encountered another issue: GDI doesn't support alpha channel, which means that GDI is unable to render anything with transparent color. A problem as before the change HTML Renderer fully supported transparent text.
To complete my previous post on text rendering in .NET I will present here the pitfalls I encountered migrating HTML Renderer to native GDI text rendering. The final result is ready to use NativeTextRenderer class with simple managed API that can be used for native GDI text rendering.
My research into text rendering in .NET/Windows started with HTML Renderer, I have noticed text issues in the rendered HTML: fonts were pixelated, letter were too close, words were either too close or too far apart (Figure 1). Although minor issues they were bugging me, also I was hoping it will lead to some performance improvements as from my last optimization session text draw/measure were the most time consuming operations.
The resulted improvement exceeded my wildest expectations and worth a post on.
I'm very happy to release another update for the project, I believe I'm getting very close to remove the 'Beta' tag from it.
This update has many fixes for complex layout and tables to handle much more complex htmls, better support for style sheet loading (see below), context menu, embedded videos and finally fixing the support for preformatted text!
I have dropped support for 'Bridge' object (see below) which can be a breaking change if used, it quite easy to replace it's use with events as can be seen in the demo application. Hopefully this will be the last version that has breaking changes.
For next version (v1.5) I'm planning to rewrite the object model (CssBox monster) and core parsing engine to significantly improve performance, especially the memory allocations that can pretty bad now for large htmls. Of course I will continue to fix bugs and add support for features as requested by the community.
Sorry for taking so long for this version I have been busy with work.
This version is focused around image and error handling (see below) with more fixes as usual.
The next version, 5-6 weeks, will have many html layout improvements so stay tuned.
I'm happy to release another update to Html Renderer project.
This release is a result of integration of the Html Renderer in actual commercial project with complex html and stylesheet (more than 400 different styles), still not perfect but much closer to WebBrowser control rendering I'm replacing.
My next big step is to add support for images so stay tuned.