Free Support Forum -

HTML to JPG rendering - setting margins in the output using .NET

Hello Supportteam,

I’m using an older version of your great product to convert documents. It’s the version 17.3 and I’m using the Viewer for conversion although the Conversion component may do it better.

Anyway, what I want to achieve works with the Viewer as well. But I have some questions in detail to better control the result.

My programming language is C# and I develop with Visual Studio 2019

So here we are.

I have an html-file which I want to convert to a jpg-File.
For this I instantiate the class ViewerImageHandler with an instance of ViewerConfig.
for the ImageOption instance I set these properties
imgOpt.ConvertImageFileType = ConvertImageFileType.JPG;
imgOpt.Height = 2970;
imgOpt.Width = 2100;

and finally I call GetPages of ViewerImageHandler like this
List Pages = imageHandler.GetPages(FilePath, imgOpt) ;

now I get a List of PageImage objects depending on the length of the html file.
From each PageImage I call CopyTo from the Stream property and convert it to a byte array. With this byte array I create an Image of namespace System.Drawing and store it on disk.

This works perfect so far.

An here are my questions:

How can I set the pagesize the number of pages depends on ?
An html-file has normally no pagesize information in it. It’s just an endless list of html elements. So when does a pagebreak happen ?

And also what about the marginvalues for left, right, top, border ?
Especiall left/right determines when a linebreak happens.

Here are two files where you see what currently happen.
The html-file is packed to and PageImage_1.jpg is the jpg of the firs page.

PageImage_1.jpg (611.7 KB) (1.4 KB)

Thanks for your support

1 Like


We are investigating this scenario. Your investigation ticket ID is VIEWERNET-2492. We’ll let you know as there’s any update.


API doesn’t provide such a feature to set page size.

No, page size does not depend on number of pages.

The page break is not under our control in this case. Why?
The rough analogy of how API converts HTML to JPG is below:

  • Open an HTML file in an office program e.g. MS Word
  • The MS Word would convert HTML into flow format and place line breaks see opened_html_in_word.png (72.7 KB)
  • Print the document and take the first page of it, see print_html.png (95.0 KB)

Margins are taken into account, the same as MS Word does, see margins.png (506.2 KB) and margins_in_word.png (74.7 KB).
Let us know if it was helpful

well, I didn’t write that pagesize depends on number of pages, in fact it is the other way round. May be my first question was a bit misleading.

If the page height shrinks then the number of pages must grow, because the same content hast to be put on smaller and therefore more pages.

Your samples with word are not very helpful.
Of course in Word everything can be set, pagesize, margins, etc. and when Word has to render the complete content on pages for printing, it takes all these settings into account.

But you have no Word behind. You have your own renderengine to transform the html content to a jpg. And to know, where the first letter of the first word has to be placed, you must have some values called leftmargin and topmargin.

image.png (10.1 KB)

And from what you wrote I understand, that these are fixed internal values, and there is no way for developers to change them.

Right ?

1 Like


Yes, that is right. These settings are not changeable.
However, if you describe your use-case in details (why do you need these settings more specifically), probably we can come up with some solution by adding an option in the future versions.

Well, what is my usecase ?

Take a look at the sample html-File I’ve attached in my initial request.
The result of the conversion are two pages, and on the second page there is only one or two lines. It’s nearly an empty page.

and if you look at the first resultpage I also attached, you see, that all margins are quite large, which isn’t neccessary. If I would be able to set smaller margins, then the complete content could be placed on one page, which is more suitable.

I guess this is a quite sensful usecase, isn’t it ?


1 Like


Thank you for the details. We are further investigating this scenario and hopeful to support such a feature in some upcoming releases. And the ETA for now is API version 20.7. As releases gets on-board, you’ll be notified.

The issues you have found earlier (filed as VIEWERNET-2492) have been fixed in this update. This message was posted using Bugs notification tool by atirtahir3