font size difference for TrueType vs. bitmap fonts

We have some some folks reporting differences in font size depending on
whether they are using TrueType or bitmap fonts. In fact, I can visually
see the difference in PED with the two “Helvetica” fonts at the same point
sizes.

What’s going on here? Is there some system setting I can change to make the
two types of fonts the same size? I’d love to see more info on fonts
anyway, like a technical article; size, speed comparisons for TrueType vs.
bitmap, etc. etc.

Patrick Mueller
Patrick_Mueller@oti.com

… hello … any one out there …

Patrick Mueller
Patrick_Mueller@oti.com



Patrick Mueller <patrick_mueller@oti.com> wrote in message
news:92t0ue$jog$1@inn.qnx.com

We have some some folks reporting differences in font size depending on
whether they are using TrueType or bitmap fonts. In fact, I can visually
see the difference in PED with the two “Helvetica” fonts at the same point
sizes.

What’s going on here? Is there some system setting I can change to make
the
two types of fonts the same size? I’d love to see more info on fonts
anyway, like a technical article; size, speed comparisons for TrueType vs.
bitmap, etc. etc.

Patrick Mueller
Patrick_Mueller@oti.com

\

Patrick Mueller <patrick_mueller@oti.com> wrote:

Patrick Mueller <> patrick_mueller@oti.com> > wrote in message
news:92t0ue$jog$> 1@inn.qnx.com> …
We have some some folks reporting differences in font size depending on
whether they are using TrueType or bitmap fonts. In fact, I can visually
see the difference in PED with the two “Helvetica” fonts at the same point
sizes.

What’s going on here? Is there some system setting I can change to make
the
two types of fonts the same size? I’d love to see more info on fonts
anyway, like a technical article; size, speed comparisons for TrueType vs.
bitmap, etc. etc.

… hello … any one out there …

I forwarded this one when you first posted it to our Photon Font
Guy, but I haven’t seen him in the building this week – still on
holidays, probably?

Anyway, rest assured the person who can answer your question will
know about it when he gets back to work.


Norbert Black
QSSL Training Services

I’m not that guy, but I have been doing lot of work with fonts and
Photon bitmap fonts in particular, so here are some hints.

Bitmap fonts in general can only match their nominal size when viewed on
a device with resolution matching the ‘internal’ font resolution. Most
bitmap font formats therefore have ‘resolution’ metric which allow one
to choose proper version of font depending on screen resolution. X
systems traditionally have 75dpi and 100dpi bitmap fonts. Windows has
‘small’ and ‘large’ fonts (but it also allows you to set scaling factor
explicitly).

The problem with Photon bitmap fonts is, they don’t have such a metric
so you have only one version for all resolutions (and they appear to be
designed for some odd resolution like 80dpi). They lack other important
metrics too, like charset, plus they have only one width metric per
glyph, which is not enough to adequately represent proportional italics
style fonts (most other bitmap formats have 2 metrics per glyph). The
format sucks, simply speaking.

The next this is how their TrueType renderer works. To render an outline
font properly it must know phisycal display resolution, which depends on
both nominal resolution and physical screen size. Theoretically it is
possible to get physical size from moderm monitors, but I very much
doubt that their drivers do that. The renderer is probably using some
‘guess’ or may be set of ‘guesses’ (depending on nominal resolution).

The bottom line, you hardly can expect bitmap 12point font to be the
same size as TT 12point, unless all stars are positioned properly on the
havens. Or unless they provide a way to adjust scaling factor for TT
fonts.

  • igor

Norbert Black wrote:

Patrick Mueller <> patrick_mueller@oti.com> > wrote:
Patrick Mueller <> patrick_mueller@oti.com> > wrote in message
news:92t0ue$jog$> 1@inn.qnx.com> …
We have some some folks reporting differences in font size depending on
whether they are using TrueType or bitmap fonts. In fact, I can visually
see the difference in PED with the two “Helvetica” fonts at the same point
sizes.

What’s going on here? Is there some system setting I can change to make
the
two types of fonts the same size? I’d love to see more info on fonts
anyway, like a technical article; size, speed comparisons for TrueType vs.
bitmap, etc. etc.

… hello … any one out there …

I forwarded this one when you first posted it to our Photon Font
Guy, but I haven’t seen him in the building this week – still on
holidays, probably?

Anyway, rest assured the person who can answer your question will
know about it when he gets back to work.

Norbert Black
QSSL Training Services

Igor, stout observations!

What Igor has indicated is explicitly true.
I believe the original bitmap fonts, that were shipped,
were based on the X 75 DPI bdf files. The default resolution
for the TrueType renderer is 96 dpi. There is a -r option
you can add to your fontopt file to change this i.e. -r100 or
-r75. In future versions of the release, there will be an option
in the fontadmin utility for different font sizes (Small, Normal,
Large, Massive).

Another issue that is faced when changing these values,
is if applications will resize properly, and that is
a whole different ball game.

Thank You.

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

I’m not that guy, but I have been doing lot of work with fonts and
Photon bitmap fonts in particular, so here are some hints.

Bitmap fonts in general can only match their nominal size when viewed on
a device with resolution matching the ‘internal’ font resolution. Most
bitmap font formats therefore have ‘resolution’ metric which allow one
to choose proper version of font depending on screen resolution. X
systems traditionally have 75dpi and 100dpi bitmap fonts. Windows has
‘small’ and ‘large’ fonts (but it also allows you to set scaling factor
explicitly).

The problem with Photon bitmap fonts is, they don’t have such a metric
so you have only one version for all resolutions (and they appear to be
designed for some odd resolution like 80dpi). They lack other important
metrics too, like charset, plus they have only one width metric per
glyph, which is not enough to adequately represent proportional italics
style fonts (most other bitmap formats have 2 metrics per glyph). The
format sucks, simply speaking.

The next this is how their TrueType renderer works. To render an outline
font properly it must know phisycal display resolution, which depends on
both nominal resolution and physical screen size. Theoretically it is
possible to get physical size from moderm monitors, but I very much
doubt that their drivers do that. The renderer is probably using some
‘guess’ or may be set of ‘guesses’ (depending on nominal resolution).

The bottom line, you hardly can expect bitmap 12point font to be the
same size as TT 12point, unless all stars are positioned properly on the
havens. Or unless they provide a way to adjust scaling factor for TT
fonts.

  • igor

Norbert Black wrote:

Patrick Mueller <> patrick_mueller@oti.com> > wrote:
Patrick Mueller <> patrick_mueller@oti.com> > wrote in message
news:92t0ue$jog$> 1@inn.qnx.com> …
We have some some folks reporting differences in font size depending on
whether they are using TrueType or bitmap fonts. In fact, I can visually
see the difference in PED with the two “Helvetica” fonts at the same point
sizes.

What’s going on here? Is there some system setting I can change to make
the
two types of fonts the same size? I’d love to see more info on fonts
anyway, like a technical article; size, speed comparisons for TrueType vs.
bitmap, etc. etc.

… hello … any one out there …

I forwarded this one when you first posted it to our Photon Font
Guy, but I haven’t seen him in the building this week – still on
holidays, probably?

Anyway, rest assured the person who can answer your question will
know about it when he gets back to work.

Norbert Black
QSSL Training Services

I would like a system where I could input the dpi (or better, it
would be read from the hardware where possible) and preferred delta
and all point sizes would be counted from there and displayed
correctly.

No messing with pixel sizes, “small” “large” etc ridiculous and abstract
setting and them all counteracting and compensating eachother.
If there’s a tag in text and my dpi is 98 and I want
the text a little larger (delta +0.7) it will render a 10.7pt, not pix,
font and show that.

The way God^WMan intended :^)

OK, interesting. My initial guesses, from experiments, were 72 and 96.

I’ve noticed some other odd things:

  • the mappings provided by QNX RTP have two Helvetica’s. One scaled, one
    bitmap. It appears that sometimes it uses the scaled, sometimes the bitmap
    via PfQueryFontInfo.

  • even for bitmap, it appears that I can get bigger fonts than I ask for.
    Are the bitmap fonts scaled up on occaison?

  • it seems like given PfQueryFontInfo’s guessing, the only way to get a
    consistent font story is to build your font maps et al so that you only have
    scaled or only bitmap. Or are there some rules I can follow to make life
    easier on myself. Yes, I’ve read the new font page in the docs. All it
    really tells you is to use the logical instead of stem name (although
    PfQueryFontInfo appears to happily accept font stems as well).

Patrick Mueller
PMuellr@yahoo.com



Derek Leach <dleach@qnx.com> wrote in message
news:93cjlm$qk8$1@inn.qnx.com

Igor, stout observations!

What Igor has indicated is explicitly true.
I believe the original bitmap fonts, that were shipped,
were based on the X 75 DPI bdf files. The default resolution
for the TrueType renderer is 96 dpi. There is a -r option
you can add to your fontopt file to change this i.e. -r100 or
-r75. In future versions of the release, there will be an option
in the fontadmin utility for different font sizes (Small, Normal,
Large, Massive).

Another issue that is faced when changing these values,
is if applications will resize properly, and that is
a whole different ball game.

Thank You.

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
I’m not that guy, but I have been doing lot of work with fonts and
Photon bitmap fonts in particular, so here are some hints.

Bitmap fonts in general can only match their nominal size when viewed on
a device with resolution matching the ‘internal’ font resolution. Most
bitmap font formats therefore have ‘resolution’ metric which allow one
to choose proper version of font depending on screen resolution. X
systems traditionally have 75dpi and 100dpi bitmap fonts. Windows has
‘small’ and ‘large’ fonts (but it also allows you to set scaling factor
explicitly).

The problem with Photon bitmap fonts is, they don’t have such a metric
so you have only one version for all resolutions (and they appear to be
designed for some odd resolution like 80dpi). They lack other important
metrics too, like charset, plus they have only one width metric per
glyph, which is not enough to adequately represent proportional italics
style fonts (most other bitmap formats have 2 metrics per glyph). The
format sucks, simply speaking.

The next this is how their TrueType renderer works. To render an outline
font properly it must know phisycal display resolution, which depends on
both nominal resolution and physical screen size. Theoretically it is
possible to get physical size from moderm monitors, but I very much
doubt that their drivers do that. The renderer is probably using some
‘guess’ or may be set of ‘guesses’ (depending on nominal resolution).

The bottom line, you hardly can expect bitmap 12point font to be the
same size as TT 12point, unless all stars are positioned properly on the
havens. Or unless they provide a way to adjust scaling factor for TT
fonts.

  • igor

Norbert Black wrote:

Patrick Mueller <> patrick_mueller@oti.com> > wrote:
Patrick Mueller <> patrick_mueller@oti.com> > wrote in message
news:92t0ue$jog$> 1@inn.qnx.com> …
We have some some folks reporting differences in font size depending
on
whether they are using TrueType or bitmap fonts. In fact, I can
visually
see the difference in PED with the two “Helvetica” fonts at the same
point
sizes.

What’s going on here? Is there some system setting I can change to
make
the
two types of fonts the same size? I’d love to see more info on
fonts
anyway, like a technical article; size, speed comparisons for
TrueType vs.
bitmap, etc. etc.

… hello … any one out there …

I forwarded this one when you first posted it to our Photon Font
Guy, but I haven’t seen him in the building this week – still on
holidays, probably?

Anyway, rest assured the person who can answer your question will
know about it when he gets back to work.

Norbert Black
QSSL Training Services

Harri Haataja <harri@tolppa.kotisivupalvelu.fi> wrote:

I would like a system where I could input the dpi (or better, it
would be read from the hardware where possible) and preferred delta
and all point sizes would be counted from there and displayed
correctly.

No messing with pixel sizes, “small” “large” etc ridiculous and abstract
setting and them all counteracting and compensating eachother.
If there’s a tag in text and my dpi is 98 and I want
the text a little larger (delta +0.7) it will render a 10.7pt, not pix,
font and show that.

The way God^WMan intended :^)

The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!
With the current architecture, the DPI cannot be retrieved from the
graphics subsystem.

The delta would be a delta of the DPI, since it is the only value
that is passed to the rendering engine used by the font manager.
Currently 96/96 is given.

Applying a delta to the “point size” would
be brutal, since it would have to be done every time a message is
received, whereas the DPI could be set, and after the cache is cleared,
symbol would render without issue. Also, all the rendering engines,
being archaic, would become royally confused by the differing “point sizes”.

Your opinions are welcome.

Thank You.

Patrick Mueller <Patrick_Mueller@oti.com> wrote:

OK, interesting. My initial guesses, from experiments, were 72 and 96.

I’ve noticed some other odd things:

  • the mappings provided by QNX RTP have two Helvetica’s. One scaled, one
    bitmap. It appears that sometimes it uses the scaled, sometimes the bitmap
    via PfQueryFontInfo.

If your are talking about ped, it is ped being naughty.
The is a newer ped which behaves itself, since I am
the one who had to correct the behaviour! It would
just scan from the top of the list, and pick the
first one encountered, among other decidedly evil things.

  • even for bitmap, it appears that I can get bigger fonts than I ask for.
    Are the bitmap fonts scaled up on occaison?

Only if a supplement is available.
Helvetica (bitmap) is supplemented by Dutch801 BT.
Bitmap fonts themselves are never scaled up.

  • it seems like given PfQueryFontInfo’s guessing, the only way to get a
    consistent font story is to build your font maps et al so that you only have
    scaled or only bitmap. Or are there some rules I can follow to make life
    easier on myself. Yes, I’ve read the new font page in the docs. All it
    really tells you is to use the logical instead of stem name (although
    PfQueryFontInfo appears to happily accept font stems as well).

PfQueryFontInfo ONLY accepts stem names.
You can remove the Helvetica mapping using fontadmin,
or delete it from the ‘fontmap’ file.

The reason it exists, is that eventually the 114 fonts
we be placed in a “legacy” package, and will not be
shipped standard.

PfGenerateFontName() will return the first one it counters,
and consistently return that one. You will have a FontID,
which you can pass to the API routine PfConvertID(). PfConvertFontID
will construct a stem name which you can use with the older
API, such as PfQueryFontInfo. When you are finished with the
FontID, you can free the resource with the API call PfFreeFont.

Any newer API routines will take a FontID pointer, and nothing
else. Alas, I hate legacy API. When dealing with the current
API:

A FontName encountered represents a stem, such as helv10.
A parameter/member called ‘font’ is a stem.
A parameter/member called ‘stem’ is a stem.
A parameter/member called desc is a foundry name, such as Helvetica, Comic Sans MS.
A parameter/member called description is a foundry name.

As stated earlies, use PfConvertFontID to retrieve the ‘stem/token’
to use with the API. Use PfFontDescription to retrieve the
foundry name.

Thank You.

Patrick Mueller
PMuellr@yahoo.com



Derek Leach <> dleach@qnx.com> > wrote in message
news:93cjlm$qk8$> 1@inn.qnx.com> …
Igor, stout observations!

What Igor has indicated is explicitly true.
I believe the original bitmap fonts, that were shipped,
were based on the X 75 DPI bdf files. The default resolution
for the TrueType renderer is 96 dpi. There is a -r option
you can add to your fontopt file to change this i.e. -r100 or
-r75. In future versions of the release, there will be an option
in the fontadmin utility for different font sizes (Small, Normal,
Large, Massive).

Another issue that is faced when changing these values,
is if applications will resize properly, and that is
a whole different ball game.

Thank You.

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
I’m not that guy, but I have been doing lot of work with fonts and
Photon bitmap fonts in particular, so here are some hints.

Bitmap fonts in general can only match their nominal size when viewed on
a device with resolution matching the ‘internal’ font resolution. Most
bitmap font formats therefore have ‘resolution’ metric which allow one
to choose proper version of font depending on screen resolution. X
systems traditionally have 75dpi and 100dpi bitmap fonts. Windows has
‘small’ and ‘large’ fonts (but it also allows you to set scaling factor
explicitly).

The problem with Photon bitmap fonts is, they don’t have such a metric
so you have only one version for all resolutions (and they appear to be
designed for some odd resolution like 80dpi). They lack other important
metrics too, like charset, plus they have only one width metric per
glyph, which is not enough to adequately represent proportional italics
style fonts (most other bitmap formats have 2 metrics per glyph). The
format sucks, simply speaking.

The next this is how their TrueType renderer works. To render an outline
font properly it must know phisycal display resolution, which depends on
both nominal resolution and physical screen size. Theoretically it is
possible to get physical size from moderm monitors, but I very much
doubt that their drivers do that. The renderer is probably using some
‘guess’ or may be set of ‘guesses’ (depending on nominal resolution).

The bottom line, you hardly can expect bitmap 12point font to be the
same size as TT 12point, unless all stars are positioned properly on the
havens. Or unless they provide a way to adjust scaling factor for TT
fonts.

  • igor

Norbert Black wrote:

Patrick Mueller <> patrick_mueller@oti.com> > wrote:
Patrick Mueller <> patrick_mueller@oti.com> > wrote in message
news:92t0ue$jog$> 1@inn.qnx.com> …
We have some some folks reporting differences in font size depending
on
whether they are using TrueType or bitmap fonts. In fact, I can
visually
see the difference in PED with the two “Helvetica” fonts at the same
point
sizes.

What’s going on here? Is there some system setting I can change to
make
the
two types of fonts the same size? I’d love to see more info on
fonts
anyway, like a technical article; size, speed comparisons for
TrueType vs.
bitmap, etc. etc.

… hello … any one out there …

I forwarded this one when you first posted it to our Photon Font
Guy, but I haven’t seen him in the building this week – still on
holidays, probably?

Anyway, rest assured the person who can answer your question will
know about it when he gets back to work.

Norbert Black
QSSL Training Services

Derek Leach wrote:

Harri Haataja <> harri@tolppa.kotisivupalvelu.fi> > wrote:
I would like a system where I could input the dpi (or better, it
would be read from the hardware where possible) and preferred delta
and all point sizes would be counted from there and displayed
correctly.

No messing with pixel sizes, “small” “large” etc ridiculous and abstract
setting and them all counteracting and compensating eachother.
If there’s a tag in text and my dpi is 98 and I want
the text a little larger (delta +0.7) it will render a 10.7pt, not pix,
font and show that.

The way God^WMan intended :^)

The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!
With the current architecture, the DPI cannot be retrieved from the
graphics subsystem.

Just let us enter it in the fontadmin. Slider or something like that.

The delta would be a delta of the DPI, since it is the only value
that is passed to the rendering engine used by the font manager.
Currently 96/96 is given.

Then have just DPI as delta to DPI makes no sense.

  • igor

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

Derek Leach wrote:
[snip]
The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!
With the current architecture, the DPI cannot be retrieved from the
graphics subsystem.


Just let us enter it in the fontadmin. Slider or something like that.

This I will do. I believe the initial reasoning of having the
Small, Normal, Large, etc was to idiot proof the interface. Is
there a range of acceptable values, maybe 72 to 150 or something
similar?

Thank You.

What fonts will become the standard fonts? Are you saying none of the
bitmap fonts will be ‘standard’. Not that I’m complaining, just want to
know.

Patrick Mueller
PMuellr@yahoo.com



Derek Leach <dleach@qnx.com> wrote in message
news:93fe29$ids$1@inn.qnx.com

PfQueryFontInfo ONLY accepts stem names.
You can remove the Helvetica mapping using fontadmin,
or delete it from the ‘fontmap’ file.

The reason it exists, is that eventually the 114 fonts
we be placed in a “legacy” package, and will not be
shipped standard.

Patrick Mueller <Patrick_Mueller@oti.com> wrote:

What fonts will become the standard fonts? Are you saying none of the
bitmap fonts will be ‘standard’. Not that I’m complaining, just want to
know.

Patrick Mueller
PMuellr@yahoo.com

PC Terminal, PC Serif, PC Sanserif, and Photon Cursor
will remain in the default package.

Swiss721 BT, Dutch801 BT, Courier 10 Pitch BT, and Wingbats SWM
will also be in the legacy package.

So, that leaves you with the following “real” fonts;

Courier10 BT
PrimaSans BT
PrimaSansMono BT
Swis721 BT
Dutch801 Rm BT
Symbol Set BT (does not contain Latin, use private Unicode range)

Other will likely be added in the future.

Thank You.


Derek Leach <> dleach@qnx.com> > wrote in message
news:93fe29$ids$> 1@inn.qnx.com> …

PfQueryFontInfo ONLY accepts stem names.
You can remove the Helvetica mapping using fontadmin,
or delete it from the ‘fontmap’ file.

The reason it exists, is that eventually the 114 fonts
we be placed in a “legacy” package, and will not be
shipped standard.

Derek Leach wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Derek Leach wrote:
[snip]
The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!
With the current architecture, the DPI cannot be retrieved from the
graphics subsystem.


Just let us enter it in the fontadmin. Slider or something like that.

This I will do. I believe the initial reasoning of having the
Small, Normal, Large, etc was to idiot proof the interface. Is
there a range of acceptable values, maybe 72 to 150 or something
similar?

On a second thought, perhaps you could add a ‘monitor viewable diagonal
size’ field?
You could calculate proper DPI value from that and resolution. And it
would be much easier to understand for normal people than DPI.

You still should have DPI field too, for those advanced/adventurous. I
think it should be auto-modified when you modify monitor size (and
perhaps rounded to some classic values like 75/96/120). Look at Windows
‘resolution’ slider which slides but assumes only certain values, not
anything.

I’m not sure also if your widget library will play well with high DPI
values. Buttons have standard sizes, expressed in pixels and if DPI is
too big the standard labels won’t fit. Now if you have widget metrics
expressed in points too, that would be fun. I’m afraid though you can’t
do that efficiently with Photon. It would need a ‘screen server’
architecture like QNX Windows was (and which I miss).

  • igor

Derek Leach wrote:

Harri Haataja <> harri@tolppa.kotisivupalvelu.fi> > wrote:

The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!

And I wasn’t flaming you for it in case the !!! was defensive stance =)

The delta would be a delta of the DPI, since it is the only value
that is passed to the rendering engine used by the font manager.

This seems to make sense, but that would also affect when you want to,
for example, preview a DTP project and it has a 10x5cm picture.
Here the delta should not come into effect but the display dpi should
be set as accurately as possible.

Overriding a value just to override it back again seems to make
little sense.

Applying a delta to the “point size” would
be brutal, since it would have to be done every time a message is
received, whereas the DPI could be set, and after the cache is cleared,
symbol would render without issue. Also, all the rendering engines,
being archaic, would become royally confused by the differing “point sizes”.

Perhaps there would be two values somehow available to the programs:
Preferred dpi (as dpi, used by all but…)
The Real dpi (… the ones that need to display sizes right)

Then again, mapping typesetting sizes etc is pretty tough issue on computers
anyway.

Your opinions are welcome.

Just for the discussion. Any ideas may be used by the readers after
the talkers seem to have reached useful conclusions =)

And if I’m “wrong” I would surely like to get facts and views that allow
me to adjust my opinions in case I get enlightened.

Harri Haataja <harri@tolppa.kotisivupalvelu.fi> wrote:

Derek Leach wrote:
Harri Haataja <> harri@tolppa.kotisivupalvelu.fi> > wrote:
[snip]
This seems to make sense, but that would also affect when you want to,
for example, preview a DTP project and it has a 10x5cm picture.
Here the delta should not come into effect but the display dpi should
be set as accurately as possible.

I wish! Unfortunately, there is no way to specify DPI per
process. Also, if this were possible, a separate bitmap cache
would be required per DPI.

FYI, there are also fractional extent/render functions
which can be used to fit a string into a specified bounding
box. Print preview does this. If we crank the display DPI to
120, the text in the print preview would still be the same
size as before.

Overriding a value just to override it back again seems to make
little sense.
[snip]
Perhaps there would be two values somehow available to the programs:
Preferred dpi (as dpi, used by all but…)
The Real dpi (… the ones that need to display sizes right)

Then again, mapping typesetting sizes etc is pretty tough issue on computers
anyway.

I think I am going to go the route suggested by Igor,
and allow the DPI to be entered into a field.

Thank You.

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

Derek Leach wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Derek Leach wrote:
[snip]
The preferred delta I can do. In hindsight, the small, large, etc
is rather annoying, but I can say in my defense, it was not my idea!!
With the current architecture, the DPI cannot be retrieved from the
graphics subsystem.


Just let us enter it in the fontadmin. Slider or something like that.

This I will do. I believe the initial reasoning of having the
Small, Normal, Large, etc was to idiot proof the interface. Is
there a range of acceptable values, maybe 72 to 150 or something
similar?


On a second thought, perhaps you could add a ‘monitor viewable diagonal
size’ field?
You could calculate proper DPI value from that and resolution. And it
would be much easier to understand for normal people than DPI.

This is a great idea, though I will implement the DPI field
first.

You still should have DPI field too, for those advanced/adventurous. I
think it should be auto-modified when you modify monitor size (and
perhaps rounded to some classic values like 75/96/120). Look at Windows
‘resolution’ slider which slides but assumes only certain values, not
anything.

For now, I will go with a numeric field, with a range of 60 to 180.
This should be sufficient for now.

I’m not sure also if your widget library will play well with high DPI
values. Buttons have standard sizes, expressed in pixels and if DPI is
too big the standard labels won’t fit. Now if you have widget metrics
expressed in points too, that would be fun. I’m afraid though you can’t
do that efficiently with Photon. It would need a ‘screen server’
architecture like QNX Windows was (and which I miss).

  • igor

I can see all the messed up application displays now!

Thank You.

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

On a second thought, perhaps you could add a ‘monitor viewable diagonal
size’ field?

Ha ha ha ha ha ha ha ha ha ha…

HA HA HA HA HA HA HA HA HA HA HA HA HA HA…

ha HA HA … COUGH COUGH… CHOKE COUGH… HA HA HA HA …

Oh Igor… sometimes you say such hilarious things. It’s hard to tell when
you’re serious.

Derek Leach <dleach@qnx.com> wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Derek Leach wrote:
On a second thought, perhaps you could add a ‘monitor viewable diagonal
size’ field?
You could calculate proper DPI value from that and resolution. And it
would be much easier to understand for normal people than DPI.
[snip]
This is a great idea, though I will implement the DPI field
first.
[snip]

Now that I have been flamed by Pete (in person nonetheless),
I will emphasize that “This is a great idea” was meant to
be sarcastic …

Oh the humanity of it all …

“Derek Leach” <dleach@qnx.com> wrote in message
news:93hs5j$3r0$1@inn.qnx.com

Derek Leach <> dleach@qnx.com> > wrote:
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Derek Leach wrote:
On a second thought, perhaps you could add a ‘monitor viewable diagonal
size’ field?
You could calculate proper DPI value from that and resolution. And it
would be much easier to understand for normal people than DPI.
[snip]
This is a great idea, though I will implement the DPI field
first.
[snip]

Now that I have been flamed by Pete (in person nonetheless),
I will emphasize that “This is a great idea” was meant to
be sarcastic …

Oh the humanity of it all …

I presume Pete flamed you flamed because he is working day and night on
extracting DPI value from graphics subsystem.

By the way, I think we should award Pete the next T-shirt. I’ll wear ‘I have
been Peted’ of course. I guess quite a few people might join me :wink:

  • igor