Re: Vector Graphics - was MFC and GDI+

The issue of "vector" graphics vs. "pixel" graphics is deep. Unfortunately, it is also
largely a dead issue because there are no vector graphics hardware devices any longer
(they are far too expensive for the consumer market and therefore there is no motivation
to create them).

The solution is to use a music font; there are several available. The font display logic
will do all kinds of tricks of creating grayscale and colored images (take a look at a
highly-magnified screen snapshot with ClearType enabled!) to fool the eye into seeing
someting that isn't really there, and give the illusion of greater detail. Without using
fonts, you haven't a chance of geting this right.

For top-of-the-line, use Adobe's "Sonata" font, it is an absolute killer font for music
typesetting.

WIthout fonts to represent your characters, they will not scale well. The font rendering
engines, however, can take into account screen rendering issues and printer rendering
issues. I would never tackle a music typesetting problem in terms of using my own bitmaps
for the musical symbols. It just won't work. (I should point out that I spent several
years writing music software using PostScript fonts. I developed the in-printer
PostScript library and sent down commands that laid out the pages, so I'm not without
substantial experience in this area). The fonts also can handle things like the staff
lines, which can end up being either one pixel or two pixels wide depending on the layout.
You either have to swtich back and forth between logical space and device space, or use
the musical staff character from the font, qhich in the case of the Adobe font, guarantees
that all staff lines will be the same width on any output device whatsoever (I drew the
font by anisotropic mapping of the font and therefore wrote exactly one character for each
mjusical line. Then I changed coordinate systems and laid the notes down on top of that).

Vector GRAPHICS representations of musical symbols don't work well because the mappings to
pixel space do not properly handle scaling, roundoff, etc.; on the other hand, font
rendering engines are EXTREMELY GOOD at handling device-specific transformations of vector
graphics to pixel graphics, and the Adobe Sonata font is particularly pleasant to work in.
We didn't use it for the screen font because the app was done in MS-DOS, but I've also
used it for some Windows work and the results were nice. We ended up using a
public-domain music font for product distribution because the licensing issues with Adobe
were too hard to deal with for a small (1-person) company, and the font we ended up using
wasn't all that bad.
joe


On Wed, 18 Apr 2007 09:32:51 +0100, "David Webber" <dave@xxxxxxxxxxxxxxxxxxx> wrote:


"Michael Phillips, Jr." <mphillips53@xxxxxxxxxxxxxxx> wrote in message
news:eQHVEiQgHHA.3460@xxxxxxxxxxxxxxxxxxxxxxx

I do not understand why you cannot use vector graphics.

The difficulty is the 5 line music stave - schematically

----------------------
----------------------
----------------------
----------------------
----------------------

On the screen (I'll come to printers in a moment) the smallest
representation (useful for overviews, not for editing details) has 1-pixel
thick lines and a 1 pixel-thick space between them. The next smallest
(useful for simultaneous editing and overview) has 1 pixel thick lines and a
3-pixel high space between them.

In either of those cases the consequence of using vector graphics and
getting a rounding error such that one line is 1 pixel out from where it
should be, is utterly catastrophic. It destroys the image completely.

[I can see this effect easily - just by opening a Print Preview window!
The resolution of the screen doesn't change but the mapping does.]

When I first wrote the code the new and latest technology was the wonderful
Epson FX80 dot-matrix printer - remember them? :-) Again absolute
pixel accurcay was completely necessary: the occasional line being drawn one
pixel to high or low, would make the music unreadable. [Remember musicians
don't get a chance to go back and re-read it if it isn't quite clear: they
have to get it right first time!]

Nowadays printers generally gave a better resolution, and my experience is
that a slight unevenness in line spacing mostly just makes the music look a
bit less crisp, rather making it completely unreadable. But there are
people who print full orchestral scores on A4 paper (because that's what
their printer has). In this case the music is small and again the printer
resolution starts to become important. Printers are very good and I can
read the results (albeit with a magnifying glass) but I doubt that would be
true with vector graphics.

You say the vector resolution is 0.01mm. At 300dpi (and lot of people
still apparently use that) pixel resolution is 0.0847mm. I don't feel that
is a sufficient safety margin! If you scale to an arbitrary size, then in
general the lines of the 5-line stave will not be separated by an integral
number of pixels. Sooner or later (soon in fact) one of the staves will
end up with unevenly spaced lines, resulting in an image degradation which
according to circumstances may be tolerable, annoying, or devastating :-(

So for now I'll stick to asking for the printer resolution, and drawing
staves to exact pixels.

This has consequences. For instance if you change printers, the height of a
5-line stave (my measure of point-size for the music font) can change by
typically 1 pt. But as the same factors affect this as affect the vector
graphics, I'll feel able to use vector graphics perhaps whan it only changes
by 0.1pt :-)

It's a pity. At one stage I thought .emf was going to answer lot of
problems, but it doesn't. In fact if you extract an image of music to paste
into Word, at bitmap constructed at printer resolution seems to work better
than emf. Word is obviously very clever about how it renders them - it
looks better than just a stretchblit!

Dave
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Font size when changing screen resolution
    ... > size after changing the screen resolution in Display Properties. ... > In order to draw the text I have converted the font point size ... > there are more logical units per pixel the lower the screen res. ... > means that a font with a certain height in logical units will draw at ...
    (microsoft.public.win32.programmer.gdi)
  • Re: How to make form resize for the screen resolution?
    ... One way is to design the form at 800x600 and scale everything up for higher resolutions. ... Large/Small system font settings have a huge impact on your coordinate system as well. ... Since Large Fonts give you 12 twips per pixel and Small Fonts give you 15 twips per pixel, ... But when I lower my resolution to ...
    (microsoft.public.vb.general.discussion)
  • Re: Frightened new owner of wide screen finds her web pages are in tiny print on it...
    ... Select the resolution that suits you. ... The set your browserto use a default font size that suits you, and hope that web authors are clever enough to let the user decide on the font size, or at least don't mess too much with it. ... One thing to be learned from this is that setting font size in pixels is a bad thing, just as setting it in points or millimeters is, though for somewhat different reasons. ... You cannot know the size of a pixel on a user's screen, and 12px might mean just illegible, or something else. ...
    (comp.infosystems.www.authoring.stylesheets)
  • Re: does anybody know how to decode TrueType glyph information?
    ... > do you still assume the current screen resolution setting is 72 DPI? ... > I guess the OP wants to obtain a font at any arbitrarily high ... The required pixel count ...
    (microsoft.public.win32.programmer.gdi)
  • Re: How to swee youtube videos,
    ... For what it's worth, US-ASCII has always been inadequate, even for plain ... Yep, despite what many would think, English, itself, uses ... The mess of font selection in Mozilla isn't their own fault? ... the pixel as the size (it's scaled, ...
    (Fedora)