12 <concept xml:lang="en" id="GUID-067BC702-4F66-5CAF-952D-7CFA35F5EB1E"><title>Twip to Pixel Mapping</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>This topic provides an introduction to two classes that embody the important GUI features of device independence and the ability to zoom. </p> <p>Two desirable facilities of a GUI are: </p> <ul><li id="GUID-BD40B76E-A127-5E3D-B166-8D875EA8DEA9"><p>device independence </p> </li> <li id="GUID-9440091B-CE23-568D-9A32-062A627A40C8"><p>zooming to reveal greater levels of detail or, conversely, more of a document </p> </li> </ul> <p>These two facilities are embodied in the two classes <codeph>MGraphicsDeviceMap</codeph> and <codeph>TZoomFactor</codeph>. </p> <p>Device independence is facilitated by storing drawings and text in device-independent form and then converting the device-independent units (twips) into device-dependent units (pixels) for different devices such as screens and printers. The conversion interface is <codeph>MGraphicsDeviceMap</codeph>, and it is implemented by graphics devices. </p> <p> <codeph>TZoomFactor</codeph> also implements this interface. It takes a mapping between twips and pixels, and then also applies a zooming factor: the larger the zooming factor, the more pixels per twip. The relationship between the classes is shown below: </p> <fig id="GUID-FE1CA913-3E44-506E-B8A6-253D169946F7"><image href="GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e206748_href.png" placement="inline"/></fig> <p>Note that <codeph>TZoomFactor</codeph> not only implements <codeph>MGraphicsDeviceMap</codeph> but also uses it. The point is that the <codeph>MGraphicsDeviceMap</codeph> -supporting object used can either be a graphics device, or another <codeph>TZoomFactor</codeph>. This allows zooming to be applied to an already zoomed mapping. </p> </conbody><related-links><link href="GUID-6AE2F937-69BB-5330-A2B5-44D37FA1DE16.dita"><linktext>Using TZoomFactor and

    12 <concept xml:lang="en" id="GUID-067BC702-4F66-5CAF-952D-7CFA35F5EB1E"><title>Twip to Pixel Mapping</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>This topic provides an introduction to two classes that embody the important GUI features of device independence and the ability to zoom. </p> <p>Two desirable facilities of a GUI are: </p> <ul><li id="GUID-BD40B76E-A127-5E3D-B166-8D875EA8DEA9"><p>device independence </p> </li> <li id="GUID-9440091B-CE23-568D-9A32-062A627A40C8"><p>zooming to reveal greater levels of detail or, conversely, more of a document </p> </li> </ul> <p>These two facilities are embodied in the two classes <codeph>MGraphicsDeviceMap</codeph> and <codeph>TZoomFactor</codeph>. </p> <p>Device independence is facilitated by storing drawings and text in device-independent form and then converting the device-independent units (twips) into device-dependent units (pixels) for different devices such as screens and printers. The conversion interface is <codeph>MGraphicsDeviceMap</codeph>, and it is implemented by graphics devices. </p> <p> <codeph>TZoomFactor</codeph> also implements this interface. It takes a mapping between twips and pixels, and then also applies a zooming factor: the larger the zooming factor, the more pixels per twip. The relationship between the classes is shown below: </p> <fig id="GUID-FE1CA913-3E44-506E-B8A6-253D169946F7"><image href="GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e201740_href.png" placement="inline"/></fig> <p>Note that <codeph>TZoomFactor</codeph> not only implements <codeph>MGraphicsDeviceMap</codeph> but also uses it. The point is that the <codeph>MGraphicsDeviceMap</codeph> -supporting object used can either be a graphics device, or another <codeph>TZoomFactor</codeph>. This allows zooming to be applied to an already zoomed mapping. </p> </conbody><related-links><link href="GUID-6AE2F937-69BB-5330-A2B5-44D37FA1DE16.dita"><linktext>Using TZoomFactor and