HTMPrintMeasure or basics of HTML/CSS printing

PrintEx API of htmlayout has HTMPrintMeasure function with the following signature:

HPRESULT HTMPrintMeasure(HTMPRINT hPrint, HDC hdc,
            int scaledWidth,
            int viewportWidth,
            int viewportHeight,
            int* pOutNumberOfPages);

I would like to explain here meanings of its parameters as I am getting questions about printing and scaling pretty frequently.


First fact that we need to know: pixels in HTML and CSS are logical units and have nothing common with device pixels our HTML/CSS is rendered on.


By accident 1px in HTML normally mapped to one physical pixel on screen (but not always, sic!) and one "HTML pixel" on printer can be mapped to some rectangular area that covers multiple printer "pixels". Strictly speaking printers have no pixels.


Showing that more device pixels (dots)
are needed to cover a 1px by 1px area on a high-resolution device than
on a low-res one   [D]
(illustration taken from W3C CSS specification)


According to the specification, HTML pixels are logical units that are just fractions of real length units:

   1px (html,css) = 1in / 96

Thus pixel in HTML is very close by its nature to "point" – 1pt is 1/72nd of an inch.


And this is it about theory, back to our business – HTMPrintMeasure function and its parameters:



  • int scaledWidth

    – is a number of "HTML pixels" between left and right border of the page.

  • int viewportWidth

    – is a number of "printer physical pixels" or dots between left and right border of the page (a.k.a. physical page width).

  • int viewportHeight

    – is a number of "printer physical pixels" or dots between top and bottom border of the page (a.k.a. physical page height).


At this point of our "printing saga" we can ask the question "what are the correct values for these parameters?"


Let’s assume that we have given:



  1. printer that has 600 dpi (dots per inch) resolution.

  2. paper of the format "legal" – 8.5 by 11 inches.

Calculation then is pretty straightforward:

viewportWidth = 600 dpi * 8.5in = 5100 dots (or printer pixels if you wish)
viewportHeight = 600 dpi * 11in = 6600 dots.
scaledWidth = 8.5in * 96 (html px per inch) = 816

Therefore we have 816 "HTML pixels" on printing page of the legal/portrait format in horizontal direction.
This means that if you have <table width=800> or <img width=800> then they shall fit on such page in full (if printing margins were set to zero).


In reality things are a bit more complex – you need to take in account printing margins in calculations to get precise results. But this I hope will not be so difficult for people who knows, let’s say, C# programming language .

HTMLayout. Success story.

Here is a success story of one of our customers. Some goverment agency in some country.

Migrating from IE control to HTMLAYOUT

Problem

We have a suite of products deployed in multiple geographical locations to about 150 clients. The suite is implemented in Law Enforcement Agencies to leverage the use of technology in ensuring the safety of our communities. The product is taking advantage of HTML to render rich User Interface (UI) content. HTML and CSS provide flexibility in the implementation of the user interface, while being extremely user friendly. Most users are familiar with browsing the internet, thus comfortable with the concepts of ‘clicking’, ‘hyperlinks’, and basic control behaviors.

Our product is rendering its user interface through Microsoft Internet Explorer controls with Microsoft Visual Basic to handle events and data manipulation. With the advent of new versions of Internet Explorer, we are anticipating a multitude of problems in rendering the User Interface. The solution is to find a third party control capable of rendering the same HTML user interface while requiring a minimum of rewriting of the existing html code base.

Solution

Our user interface is a transformation of the data retrieved from the database into HTML by using XML/XSLT transformation. We have a variety of XSLT documents that render the user interface. By implementing HtmLayout into our legacy products, we are able to continue rendering the same UI while making a minimum of changes to the XSLT. Any discrepancy in the usability is minimum and unnoticed by our client base.

HtmLayout is straight forward in its implementation and provides a number of valuable advanced capabilities. Most of the standard HTML and CSS code is portable from IE to HtmLayout. With ‘Behaviors’, it is easy to link the HTML events to code in Visual Basic. Behaviors are also used to enhance the standard functionality of HtmLayout.

HtmLayout is bringing stability into the User Interface as it is not depending on Microsoft Internet Explorer model. HtmLayout ensures User Interface consistency throughout our products.

Why HtmLayout:
• Ease of use
• Ease of migration from IE
• Support standard HTML and CSS
• Minimum investment in conversion of HTML
• Implementation of custom ‘behaviors’
• No scripting (vbscript/javascript), fewer technologies involved = fewer defects
• Simplify pages, thus reducing risk of defects
• Robust handling of messages between HTML and VB
• Responsive support team

Windowless HTMLayout

Build #3.1.1.45 of HTMLayout contains new set of API functions allowing to use htmlayout in windowless mode.

There are cases where such windowless mode (to be precise HWND-less) is needed.

Think about games. They use DirectX surfaces and implement window or view structures internally. Now HTML can be used inside such internal views.

H-SMILE core. Popup and context menus (HTMLayout and Sciter engines)

For references in this article use std-menus.css file.

Popup menus

Popup menus are designed as set of behaviors menu-bar, menu and popup-menu. As always in the engine behaviors are applied to the DOM elements by CSS attribute behavior.

Menus in the engine are ordinary DOM elements thus can be styled in full by using CSS declarations. The behaviors handle mouse and keyboard events allowing to do navigation through menu items. Content of menus is not limited by only menu items – you can use any reasonable markup inside including input elements. By using input elements it is possible to implement lightweight property sheets by using engine. See Context Menus section.

Continue reading “H-SMILE core. Popup and context menus (HTMLayout and Sciter engines)”