----- Original Message -----
From: "Walter Hofmeister" <[EMAIL PROTECTED]>
To: <lilypond-user@gnu.org>
Sent: Wednesday, June 14, 2006 10:56 AM
Subject: Re: barline problem
On 6/14/06 9:42 AM, "Erik Sandberg" <[EMAIL PROTECTED]> wrote:
On Wednesday 14 June 2006 17:25, Stephen wrote:
----- Original Message -----
From: "Dewdman42" <[EMAIL PROTECTED]>
To: <lilypond-user@gnu.org>
Sent: Tuesday, June 13, 2006 4:55 PM
Subject: Re: barline problem
Which gets us to the crux of the problem. Finale and lilypond use all
of
the
nuances of postscript that they possibly can..perhaps even using parts
of
it
that the PDF "subset" does not support very well. For this reason, all
the
PDF viewers I have tried look like crap. Sad.
Your right, Lilypond does not produce PDF files, ghostscript does. So
the
only thing Lilypond could do is add additional hinting in the PostScript
file as Hans has already suggested. And as you've already pointed out,
what
matters is how the music looks printed out. It is inadviseable to
practice
your instrument looking at the 72 dpi of the computer screen rather than
a
300 dpi printed score. That's bad for your eyes.
I think there exist music stands consisting of TFT displays nowadays, so
good
on-screen rendering is desirable to some extent. However, I'd advise to
produce png output if you want to view output on screen; because pngs
display
a lot faster than pdf or ps, and
The PDF files certainly
are perfectly readable and legible, so therefore, I don't think it is
sad
or even undesireable to have the slight aliasing issues you see. After
all,
72 dpi will always be inferior to 300 dpi no matter how you slice it. If
Lilypond is optimized for 300 dpi, that is a good thing.
btw, lily is optimized for 600 dpi iirc: the stems have slightly rounded
edges, this is not visible on resolutions below 600dpi.
I'm not sure that Lilypond is "optimized" for any set resolution as
postscript is a device/resolution independent system. That is it is your
interpreter/printing device that determines what the final resolution is.
I strongly suspect that Eric knows what PostSript is. Just because
PostScript is designed to allow rendering at any resolution, does not mean
that the basic images are not drawn initially at a specific size. The glyphs
in truetype fonts are stored in a specific resolution, as I rememnber it,
they are drawn on a square of 2048x2048 internally.
QUOTE:
" FUnits and the grid
... The points represent locations in a grid whose smallest addressable unit
is known as an FUnit or font Unit. The grid is a two-dimensional coordinate
system whose x-axis describes movement in a horizontal direction and whose
y-axis describes movement in a vertical direction. The grid origin has the
coordinates (0,0). The grid is not an infinite plane. Each point must be
within the range -16384 and +16383 FUnits. Depending upon the resolution
chosen, the range of addressable grid locations will be smaller.
The choice of the granularity of the coordinate grid-that is, number of
units per em (upem)-is made by the font manufacturer. Outline scaling will
be fastest if units per em is chosen to be a power of 2, such as 2048.
...
FUnits are relative units because they vary in size as the size of the em
square changes. The number of units per em remains constant for a given font
regardless of the point size. The number of points per em, however, will
vary with the point size of a glyph. An em square is exactly 9 points high
when a glyph is displayed at 9 points, exactly 10 points high when the font
is displayed at 10 point, and so on. Since the number of units per em does
not vary with the point size at which the font is displayed, the absolute
size of an FUnit varies as the point size varies.
...
Converting FUnits to pixels
Values in the em square are converted to values in the pixel coordinate
system by multiplying them by a scale. This scale is:
pointSize * resolution / ( 72 points per inch * units_per_em )
where pointSize is the size at which the glyph is to be displayed, and
resolution is the resolution of the output device. The 72 in the denominator
reflects the number of points per inch.
For example, assume that a glyph feature is 550 FUnits in length on a 72 dpi
screen at 18 point. There are 2048 units per em. The following calculation
reveals that the feature is 4.83 pixels long.
550 * 18 * 72 / ( 72 * 2048 ) = 4.83 "
My point is that in such systems there has to be a 'choice of the
granularity' for storing the images, or rather I should say 'for describing
the images' since the images are not stored as a bitmap.
Sorry for the long post. The distinction between the FUnit and the em is a
good analogy for how PostScript works.
Stephen
I print out using a 1200 dpi postscript printer and the output looks
great.
Walter Hofmeister
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
