Date: Sun, 14 Mar 2004 14:34:56 +0100
From: Eva Jaksch
Subject: Some tests of postscript vs. bitmapped slurs

Hello everyone,

In  the  interests  of  bringing  my  typesettings into line with more
up-to-date fonts, I've been experimenting a little with different slur
packages.  I  used  my  guitar  edition  of  BWV 995 as a test both of
backwards compatibility and slur appearance/behaviour.

My software setup is MikTeX 2.1.8, GSView 3.3, Acrobat Reader 5.0.

I created the PS files using DVIPS and the PDFs by converting PS files
from within GSView.


File sizes (in bytes):
=====================

Bitmapped slurs:   DVI 224188; PS 393575; PDF 489335
Kneifl slurs:      DVI 410040; PS 545138; PDF 540902
Morimoto slurs:    DVI 234700; PS 997311; PDF 614099


Backwards compatibility:
=======================

Morimoto: no problems encountered

Kneifl:  slurs  coded  with MusixTeX beam slur macros do not terminate
correctly (they seem to be treated like normal slurs)


Appearance:
==========

Both  the  Kneifl  and Morimoto slurs are thinner than their bitmapped
counterparts.  The Morimoto slurs appear to have a shallower curvature
than  either  the  Kneifl  or  the bitmapped slurs. This can result in
poorer  legibility at certain curvatures, with slurs standing out less
clearly against the staff lines.

The Kneifl slurs appear to have a slightly stronger curvature than the
bitmapped  slurs.  This  improves the appearance of very short (solid)
slurs,  e.g.  between  semiquavers  spaced  close together and between
grace notes and normal notes.

The  odd  slur  shape of some bitmapped slurs (depending on length and
angle) is greatly improved in both Postscript versions.


Dotted slurs:
============

Neither  set  of  Postscript slurs is satisfactory here. My test score
contains  a  large  number  of  editorial,  articulatory slurs between
closely spaced semiquavers. Using the bitmapped slur fonts, even these
short  slurs  are  drawn  with  five segments separated by very narrow
gaps.

In  contrast,  however,  both  the  Morimoto  and the Kneifl slurs use
larger  slur segments and wider gaps. As a result, my short slurs came
out  with  only two segments and a fairly wide gap in between. This is
less  clearly  legible  on  the  staff  and,  when printed out, may be
mistaken  for  a  printout  quality problem rather than a deliberately
dotted slur.

Longer  slurs too tend to be less legible against the staff lines both
in  the  Morimoto  and the Kneifl variants because of the thinner line
and  the  wide  gaps. In the case of the Morimoto slurs, the shallower
curvature  has  an  additional detrimental effect on the legibility of
some dotted slurs.


Additional comments on Morimoto slurs:
=====================================

Processing  time  is several times longer than for bitmapped or Kneifl
slurs.  The  musixpss.exe/Metapost  run took a couple of minutes on my
system  (1800MHz  CPU,  512  MB RAM) and created 490 (four hundred and
ninety)  small auxiliary files in the working directory. This may have
been  too much for my TeX shell (Crimson Editor 3.51) to handle, as it
crashed at the end of the run.


Conclusion:
==========

For  my  purposes, the bitmapped slurs still seem to be my best bet in
any score that needs to distinguish solid from dotted slurs. This is a
pity  as  the  bitmapped  slurs can produce some odd shapes in certain
situations,  and  both  of the Postscript variants appear to give more
pleasing  results  here; however, in my opinion legibility and clarity
of  intent does take priority over prettiness of line. I also find the
file size increase disappointing with both Postscript options.

As  for the problem of Acrobat Reader not displaying bitmapped ties, I
am  able  to  circumvent  this  problem  on my system (Acrobat 5.0) by
avoiding  the  use  of dvipdfm. PDFs generated with this utility don't
show  ties;  the  same source file taken through dvips and the Convert
function  of  GSView  displays flawlessly on my machine.

Where  backwards  compatibility  is not an issue (or in the case of an
existing  score  that  does not contain MusixTeX beam slurs) and where
dotted  slurs  are  not  needed, my preference would be for the Kneifl
slurs both on appearance and ease of use (no extra executables to run,
no additional auxiliary files created).

Eva Jaksch
*****************************************************************
*                                                               *
*                                                               *
* Here is an addendum by Eva on the appearance of dashed slurs: *
*                                                               *
*                                                               *
*****************************************************************
On Sunday, March 14, 2004, Stanislav Kneifl wrote:

> to your dash problem: try to locate in the the psslurs.pro the
> following line:

> { [internote 8 mul AR internote 5 mul AR] 0 setdash } if

> the figures 8 and 5 designate the width of the segment and gap
> respectively (if I remember it well). You can do some
> experiments (it's sufficient to do only the dvips pass, no need
> to run TeX) and let me know if you find out some more suitable
> values for the next release of musixps.

Dear Stanislav,

You remembered perfectly, and changing the values as follows:

{ [internote 3 mul AR internote 2 mul AR] 0 setdash }

produces  a  dash-to-space  ratio very similar to that of the original
bitmapped  slurs.  The  result  is extremely legible in all situations
where the previous values were unsatisfactory.

Well,  in practice it looks as though your slurs are mostly compatible
with  the old macros anyway! If it weren't for the beam slurs, my test
runs  suggest that one would be able to convert existing scores simply
by adding "\input musixps" to the file header.

Eva