Board index » delphi » font pixels on screen and printer

font pixels on screen and printer

Hi,

I want text on my computer screen and printer to take relatively the same
amount of pixels horizontally.

Currently relatively Form.Canvas.TextExtent(...).cx <
Printer.Canvas.TextExtent(...).cx even if both canvases use the same font.
By relatively I mean, for instance, that if my printer has 5 times more
pixels per inch than my screen then now, anyhow,
Printer.Canvas.TextExtent(...).cx/5 > Form.Canvas.TextExtent(...).cx. Why
this disparity and how to avoid it? I am using Delphi 5.

--
Kari Kauppila

e-mail: kari.kaupp...@pikotec.fi

 

Re:font pixels on screen and printer


Quote
> I want text on my computer screen and printer to take relatively the same
> amount of pixels horizontally.

> Currently relatively Form.Canvas.TextExtent(...).cx <
> Printer.Canvas.TextExtent(...).cx even if both canvases use the same font.
> By relatively I mean, for instance, that if my printer has 5 times more
> pixels per inch than my screen then now, anyhow,
> Printer.Canvas.TextExtent(...).cx/5 > Form.Canvas.TextExtent(...).cx. Why
> this disparity and how to avoid it? I am using Delphi 5.

This is because pixels are based entirely on the device properties and not
on real units. Take the following example:

If your printer is capable of running at 600x600dpi (dots per inch), and you
draw a line that is 4 inches long on it, it will wind up 600x4=2400 pixels
long.

If your screen resolution is set to 1024x768 and your're screen is 12 inches
across (horizontally), your screen has an effective resolution of 85 pixels
per inch horizontally. In this case, the same 4 inch line will wind up as
being 85x4=340 pixels long.

However, you'll find that the combination of your display screen and video
card rarely result in a situation where one inch will ever come out at one
inch. For fonts, this is even worse because users can change the settings
from normal size (stupidly called "small" by MS) and large, or some other
custom value. In this case a font that would take up one inch of screen
estate will take up something else entirely.

As a result if you want to compare text and / or graphics sizes you need to
convert both into a standard unit and work with that. It's at this point you
wonder why the dot resolution is described in inches, the resolution in
centimetres and the size in points... but that's something we have to live
with.

Hope this helps a little

Nick

Re:font pixels on screen and printer


The problems started when I wanted to print pictures that had captions. I
could easily scale the pictures so that no matter how many there were side
by side on the screen they were nicely printed on my printer (side by side,
size decreased),  but their captions started to overlap. Even if on the
screen the length of a caption was equal to the width of the corresponding
picture (in pixels), it wasn't when printed. The printed captions needed
more pixels horizontally than the scaled pictures. The font did not 'scale'
proportionally.

The pictures I simply scaled by calculating the ratio of pixels on my
printer and screen in the horizontal direction. I my experiment I did not
care if the pictures were smaller when printed. Perhaps I simply decrease
the size of font when printing to prevent overlapping?

--
Kari Kauppila

e-mail: kari.kaupp...@pikotec.fi

Quote
"Nick Ryan" <nom...@nomail.com> wrote in message news:3be92da4_2@dnews...

> This is because pixels are based entirely on the device properties and not
> on real units. Take the following example:

> If your printer is capable of running at 600x600dpi (dots per inch), and
you
> draw a line that is 4 inches long on it, it will wind up 600x4=2400 pixels
> long.

> If your screen resolution is set to 1024x768 and your're screen is 12
inches
> across (horizontally), your screen has an effective resolution of 85
pixels
> per inch horizontally. In this case, the same 4 inch line will wind up as
> being 85x4=340 pixels long.

> However, you'll find that the combination of your display screen and video
> card rarely result in a situation where one inch will ever come out at one
> inch. For fonts, this is even worse because users can change the settings
> from normal size (stupidly called "small" by MS) and large, or some other
> custom value. In this case a font that would take up one inch of screen
> estate will take up something else entirely.

> As a result if you want to compare text and / or graphics sizes you need
to
> convert both into a standard unit and work with that. It's at this point
you
> wonder why the dot resolution is described in inches, the resolution in
> centimetres and the size in points... but that's something we have to live
> with.

> Hope this helps a little

> Nick

Re:font pixels on screen and printer


Kari,

Here's what I've done with similar problems:
1. Calculate how many x-pixels you have for the caption (the width of your
picture, in your case).
2. Choose the largest font size you would like to use, say 12.  Use
printer.canvas.TextWidth(sCaption) to see how wide the caption would be in
this font.  While this width is greater then the number of x-pixels,
decrease the font size (and recalculate printer.canvas.TextWidth(sCaption))
until it fits.
Note that you have to decide whether it is acceptable to have pictures with
different font sizes, or if you need to look at the entire page, calculate
all font sizes this way, then pick the smallest.

HTH,
Thomas Pugh
tpugh-at-quest.com

Quote
"Kari Kauppila" <kari.kaupp...@pikotec.fi> wrote in message

news:3be9383b_2@dnews...
Quote
> The problems started when I wanted to print pictures that had captions. I
> could easily scale the pictures so that no matter how many there were side
> by side on the screen they were nicely printed on my printer (side by
side,
> size decreased),  but their captions started to overlap. Even if on the
> screen the length of a caption was equal to the width of the corresponding
> picture (in pixels), it wasn't when printed. The printed captions needed
> more pixels horizontally than the scaled pictures. The font did not
'scale'
> proportionally.

> The pictures I simply scaled by calculating the ratio of pixels on my
> printer and screen in the horizontal direction. I my experiment I did not
> care if the pictures were smaller when printed. Perhaps I simply decrease
> the size of font when printing to prevent overlapping?

> --
> Kari Kauppila

> e-mail: kari.kaupp...@pikotec.fi

> "Nick Ryan" <nom...@nomail.com> wrote in message news:3be92da4_2@dnews...

> > This is because pixels are based entirely on the device properties and
not
> > on real units. Take the following example:

> > If your printer is capable of running at 600x600dpi (dots per inch), and
> you
> > draw a line that is 4 inches long on it, it will wind up 600x4=2400
pixels
> > long.

> > If your screen resolution is set to 1024x768 and your're screen is 12
> inches
> > across (horizontally), your screen has an effective resolution of 85
> pixels
> > per inch horizontally. In this case, the same 4 inch line will wind up
as
> > being 85x4=340 pixels long.

> > However, you'll find that the combination of your display screen and
video
> > card rarely result in a situation where one inch will ever come out at
one
> > inch. For fonts, this is even worse because users can change the
settings
> > from normal size (stupidly called "small" by MS) and large, or some
other
> > custom value. In this case a font that would take up one inch of screen
> > estate will take up something else entirely.

> > As a result if you want to compare text and / or graphics sizes you need
> to
> > convert both into a standard unit and work with that. It's at this point
> you
> > wonder why the dot resolution is described in inches, the resolution in
> > centimetres and the size in points... but that's something we have to
live
> > with.

> > Hope this helps a little

> > Nick

Re:font pixels on screen and printer


Quote
Kari Kauppila wrote:
> The problems started when I wanted to print pictures that had captions. I
> could easily scale the pictures so that no matter how many there were side
> by side on the screen they were nicely printed on my printer (side by side,
> size decreased),  but their captions started to overlap. Even if on the
> screen the length of a caption was equal to the width of the corresponding
> picture (in pixels), it wasn't when printed. The printed captions needed
> more pixels horizontally than the scaled pictures. The font did not 'scale'
> proportionally.

True WYSIWIG, if that is what you are after, is not always that easy.
One possible way of action in this case may be drawing the captions on a
sufficiantly large bitmap and scaling them from there to either the
screen or printer. That is one way of making sure that the same actual
character drawing ends up on both devices, even though they have a
different scale need. The obvious dissadvantage is the need for this
possibly big temporary bitmap (it'll have to be big enough to make the
characters not seem jaggy when stretched to the printer canvas).

Joris

Re:font pixels on screen and printer


Quote

> True WYSIWIG, if that is what you are after, is not always that easy.
> One possible way of action in this case may be drawing the captions on a
> sufficiantly large bitmap and scaling them from there to either the
> screen or printer. That is one way of making sure that the same actual
> character drawing ends up on both devices, even though they have a
> different scale need. The obvious dissadvantage is the need for this
> possibly big temporary bitmap (it'll have to be big enough to make the
> characters not seem jaggy when stretched to the printer canvas).

> Joris

We wouldn't need so much fiddling if we had a Metafile object
functionning
correctly. Who knows, maybe we'll get one in Delphi7.0 ?

Jacques

Re:font pixels on screen and printer


Quote
Jacques Oberto wrote:
> We wouldn't need so much fiddling if we had a Metafile object
> functionning
> correctly. Who knows, maybe we'll get one in Delphi7.0 ?

Whatever Delphi offers is but an encapsulation of what the OS offers.
Metafiles are windows stuff, basically, Delphi VCL merely encapsulates
in convinient objects.

Anyway, even a good metafile object would not solve things properly
here. The metafile gets rendered upon a raster, using such things as the
windows font renderer, in exactly the same way the original poster did.
It'll show the same problems, even if it will ever be functioning
correctly.

In my opinion, any such things are not the OS's responsability, anyway.
Windows should interface you with the environment, like it does.
Blitting and font rendering are correctly considered part of that
'interfacing with the environment'. Fancy high-level programming like
WYSIWYG functionality and such is up to you.

Joris

Re:font pixels on screen and printer


Quote
Joris Van Damme wrote:

> Whatever Delphi offers is but an encapsulation of what the OS offers.
> Metafiles are windows stuff, basically, Delphi VCL merely encapsulates
> in convinient objects.

> Anyway, even a good metafile object would not solve things properly
> here. The metafile gets rendered upon a raster, using such things as the
> windows font renderer, in exactly the same way the original poster did.
> It'll show the same problems, even if it will ever be functioning
> correctly.

> In my opinion, any such things are not the OS's responsability, anyway.
> Windows should interface you with the environment, like it does.
> Blitting and font rendering are correctly considered part of that
> 'interfacing with the environment'. Fancy high-level programming like
> WYSIWYG functionality and such is up to you.

> Joris

You're absolutely right since the Metafile problems I was thinking of
in my previous post have to do with fonts. So I will rephrase my wish:
let's hope Delphi 7.0 will offer a fixed (and Windows GDI-independent)
font mapper !

Jacques

Re:font pixels on screen and printer


"Joris Van Damme" <as.van.damme.jo...@planetinternet.be> wrote in message
news:3BEA89AB.C490632@planetinternet.be...

Quote
> Anyway, even a good metafile object would not solve things properly
> here. The metafile gets rendered upon a raster, using such things as the
> windows font renderer, in exactly the same way the original poster did.
> It'll show the same problems, even if it will ever be functioning
> correctly.

You're not correct.

Metafile records individual charcter cell positions of Textout outputs
to minimize device dependence.

Re:font pixels on screen and printer


Quote
Jacques Oberto wrote:
> So I will rephrase my wish:
> let's hope Delphi 7.0 will offer a fixed (and Windows GDI-independent)
> font mapper !

Not likely. There are other font renderers though. I seem to remember
there is a public libary for truetype font rendering, too, that does
meet these needs better. I can't remember its name though.

Joris

Please do not reply private to mail posted in newsgroups or mailing
lists, unless that was agreed upon first.
When posting to newsgroups or mailing lists, please make sure you read
these guidelines first:
  http://web.infoave.net/~dcalhoun/nnq/nquote.html
  http://www.borland.com/newsgroups/netiquette.html

Re:font pixels on screen and printer


Quote
Takuo Nakamura wrote:
> Metafile records individual charcter cell positions of Textout outputs
> to minimize device dependence.

I didn't think so... but I may be mistaking.

Joris

Please do not reply private to mail posted in newsgroups or mailing
lists, unless that was agreed upon first.
When posting to newsgroups or mailing lists, please make sure you read
these guidelines first:
  http://web.infoave.net/~dcalhoun/nnq/nquote.html
  http://www.borland.com/newsgroups/netiquette.html

Re:font pixels on screen and printer


"Joris Van Damme" <as.van.damme.jo...@planetinternet.be> wrote in message
news:3BEC3BEE.1A9060F7@planetinternet.be...

Quote
> Takuo Nakamura wrote:
> > Metafile records individual charcter cell positions of Textout outputs
> > to minimize device dependence.

> I didn't think so... but I may be mistaking.

When recording TextOut, ExtTextOut, or DrawText, Enhanced Metafile creates
EMREXTTEXTOUA or EMREXTTEXTOUTW record with lpdx parameter.
Enhanced metafile also records aspect ratio of the device in EMREXTTEXTOUTA
or EMREXTTEXTOUTW record.

Almost all cases, playing of this record works fine, but in case of some
note computer
with 2:1 LCD Panel with NT or 2000, it does not, because NT and 2000 does
not report
correct aspect ratio of Screen device. This problem can be avoid by
explicitly
specify lfWidth of Logical font.
# Delphi does not specify lfWidth to create fonts.So use CreateFont
explicitly.

Re:font pixels on screen and printer


Quote
Joris Van Damme wrote:
> I seem to remember there is a public libary for truetype font rendering,
> too, that does meet these needs better. I can't remember its name though.

FreeType <http://www.freetype.org>

HTH
Clemens

Re:font pixels on screen and printer


Do you know if by any chance there is a working Delphi
implementation of the FreeType package?  I looked at
it recently and it only seems to contain old BP7 Pascal
code. Thanks.

Jacques

Quote
Clemens Ladisch wrote:

> Joris Van Damme wrote:
> > I seem to remember there is a public libary for truetype font rendering,
> > too, that does meet these needs better. I can't remember its name though.

> FreeType <http://www.freetype.org>

> HTH
> Clemens

Re:font pixels on screen and printer


Quote
Jacques Oberto wrote:
> Do you know if by any chance there is a working Delphi
> implementation of the FreeType package?

The INSTALL file in the ftpascal directory of the current CVS says:
| Contains the 1.4  release of the Pascal version  of the FreeType
| library.  It is written in  "portable" TurboPascal and has  been
| successfully  compiled with  Turbo Pascal  6 and 7, Turbo Pascal
| for Windows 1, Borland  Pascal  7, Virtual  Pascal, Free  Pascal
| and Delphi (1, 2, 3 and 4).

HTH
Clemens

Other Threads