Why is %%PageMedia: a4 hardcoded?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is %%PageMedia: a4 hardcoded?

John Hawkinson
Hello.

    As you may have noted from email to lilypond-user, I'm in the
midst of preparing some patches to improve lilypond's handling of
custom paper sizes.

    In reviewing recent code changes, I'm puzzled by some changes in
rev 1.152 of framework-ps.scm, under this log entry:

revision 1.152
date: 2006-03-06 13:42:18 +0000;  author: hanwen;  state: Exp;  lines: +33 -15
(paper-alist): no decimals for Ax paper sizes.

The revision seems to do a whole lot more, including replacing the
output of %%DocumentPaperSizes with %%DocumentMedia.  But it also
makes this change:

-    (display (page-header paper page-count #t) port)
+    (display (file-header paper page-count #t) port)
+    (display "\n%%BeginDefaults
+%%PageMedia: a4
+%%EndDefaults\n" port)
+

This hardcodes that section in the output. It seems wrong for two
reasons:

1. Not everyone uses A4.

2. It is not consistent with the definition of %%PageMedia
        on pp. 78-79 of the DSC Conventions spec.
        http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

  a) The operand to %%PageMedia is not a paper size. It is a
        <medianame>, which isn't necessarily a paper size. This is also
        true of the first operand %%DocumentMedia, by the way.

        All the examples are things like "Regular," "Cover," "BlueCL,"
        etc. A media name refers to a collection {<width>, <height>,
        <weight>, <color>, <type>} and not to some sort of external
        standard papersize.

  b) Any medianame used in %%PageMedia is supposed to be defined
        in the %%DocumentMedia (which lists all media used in the
        document). %%PageMedia is an override (for example,
        to be used per-page), though it can be used globally, too.

  c) %%PageMedia is supposed to be accompanied by relevant postscript
        code to select the media in question. E.g. from p.79:

          ...
          %%Page: Cover 1
          %%PageMedia: Cover
          %%BeginPageSetup
          /olddevice currentpagedevice def
          << /MediaColor (yellow) >> setpagedevice % Set up the yellow paper
          /pagelevel save def % for this page
          %%EndPageSetup
          ...

        It does not really make sense (I think) without such accompanying
        PostScript code.

   d) It's unnecessary. Size selection should either be performed by
        reading %%DocumentMedia (DSC-compliant document managers)
        or with the /PageSize setpagedevice key (printers; my
        forthcoming patch will do this).

Anyhow, it looks to me that this code is just wrong. Can it just go
away, please? (patch follows)

--[hidden email]
  John Hawkinson

p.s.: Is there a reason that LilyPond source files don't include
RCS expansion keywords (i.e. $Header$ or $LilyPond$)? They are often
quite handy when there are multiple versons of files
floating around...

ChangeLog entry:

2006-04-16  John Hawkinson  <[hidden email]>

        * scm/framework-ps.scm: Remove erroneous %%PageMedia: a4

Index: framework-ps.scm
===================================================================
RCS file: /sources/lilypond/lilypond/scm/framework-ps.scm,v
retrieving revision 1.160
diff -u -r1.160 framework-ps.scm
--- framework-ps.scm 4 Apr 2006 10:13:04 -0000 1.160
+++ framework-ps.scm 16 Apr 2006 07:05:57 -0000
@@ -446,9 +446,6 @@
 
     (output-scopes scopes fields basename)
     (display (file-header paper page-count #t) port)
-    (display "\n%%BeginDefaults
-%%PageMedia: a4
-%%EndDefaults\n" port)
 
     (write-preamble paper #t port)
 


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

Johannes Schindelin
Hi,

On Sun, 16 Apr 2006, John Hawkinson wrote:

> +    (display "\n%%BeginDefaults
> +%%PageMedia: a4
> +%%EndDefaults\n" port)

Correct me if I'm wrong, but was "BeginDefaults" not the method of choice
to say: if no other value is given, please take A4 instead of that
awkward Letter format?

IOW, if another page media is chosen, this should not hurt.

And BTW, Lily's PostScript code's main purpose is to produce something
which Ghostscript turns into a PDF. So, the PostScript does not have to
adher strictly to the specs, but to what Ghostscript understands.

Ciao,
Dscho



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

David Feuer-2
On 4/16/06, Johannes Schindelin <[hidden email]> wrote:

> And BTW, Lily's PostScript code's main purpose is to produce something
> which Ghostscript turns into a PDF. So, the PostScript does not have to
> adher strictly to the specs, but to what Ghostscript understands.

Next month, if all goes well, I will change this.

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

John Hawkinson
In reply to this post by Johannes Schindelin
Johannes Schindelin <[hidden email]> wrote on Sun, 16 Apr 2006
at 13:46:16 +0200 in <[hidden email]>:

> > +    (display "\n%%BeginDefaults
> > +%%PageMedia: a4
> > +%%EndDefaults\n" port)
>
> Correct me if I'm wrong, but was "BeginDefaults" not the method of choice
> to say: if no other value is given, please take A4 instead of that
> awkward Letter format?

No, that's not what it is at all. You may find it instructive to refer
to the specification.
http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf     

First of all, the %%PageMedia is used to specify that the
described attribute is "INVOKED on this page" [emphasis mine].
That is, it implies that there is postscript code on that
page which sets the media type (with setpagedevice).

Second, when %%PageMedia appears in the BeginDefaults/EndDefaults
section, it applies to *all* pages. You are only supposed to do this
if your document uses more than one type of medium, because otherwise
the specification in %%DocumentMedia would suffice. See the note at
the top of p. 49 (section 5.2):

| In some instances it may be superfluous to use these page defaults. If
| only one type of orientation, media type, etc. is used in the entire
| document, the header comment alone is sufficient to indicate the
| default for the document. PAGE DEFAULTS SHOULD ONLY BE USED IF THERE
| IS MORE THAN ONE bounding box, custom color, MEDIUM, orientation,
| process color, requirement, or resource USED.
[emphasis mine]

Third, PageMedia is meaningless when it references a medianame that is not
defined in %%DocumentMedia.


Fourth, A4 is the wrong media type for many people (fortunately since
the code doesn't accomplish anything, it only serves to confuse some
people [and perhaps some software]) who read the code, since it is
unconditionally output (but other code, including %%DocumentMedia,
properly specifies the paper size).

> IOW, if another page media is chosen, this should not hurt.

Err, it's wrong and doesn't beenfit and adds confusion.


Hopefully that's sufficiently clear? :)

> And BTW, Lily's PostScript code's main purpose is to produce something
> which Ghostscript turns into a PDF. So, the PostScript does not have to
> adher strictly to the specs, but to what Ghostscript understands.

Yikes, really!? That's good to know, I guess, but also kind of
disappointing.  For some reason that I have not bothered to debug,
PDFs that LilyPond (2.6.3) generates for me have bizarre defects, like
all text turning into the letter "y," etc. As such, postscript is the
way to go. Not to mention that it's faster.

--jhawk

p.s.: In moving from LilyPond 2.6.3 to 2.9.2, I find that spooling
postscript crashes my HP LaserJet 8150DN.  Haven't finished
figuring out why yet... I'll get there...


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

John Hawkinson
I <[hidden email]> wrote (quite a few hours ago...) on Sun, 16 Apr 2006
at 10:55:43 -0400 in <[hidden email]>:

> p.s.: In moving from LilyPond 2.6.3 to 2.9.2, I find that spooling
> postscript crashes my HP LaserJet 8150DN.  Haven't finished
> figuring out why yet... I'll get there...

It appears that this broke between 2.7.36 and 2.7.38,
and it seems to be a result of the massive font changes
that happened therein (apparently moving to embedding
opentype fonts instead of Type 1 fonts?).

I can't seem to find a discussion of the rationale for all of this on
lilypond-{user,devel} or bug-lilypond. Am I just missing it, or could
someone point me to the discussion?


Perhaps it has something to do with my print spooling environment, but
it seems like the non-eight-bit-clean nature of the generated
PostScript is likely to be my problem...

Thanks for any pointers...

--jhawk


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

Johannes Schindelin
In reply to this post by John Hawkinson
Hi,

On Sun, 16 Apr 2006, John Hawkinson wrote:

> Johannes Schindelin <[hidden email]> wrote on Sun, 16 Apr 2006
> at 13:46:16 +0200 in <[hidden email]>:
>
> > > +    (display "\n%%BeginDefaults
> > > +%%PageMedia: a4
> > > +%%EndDefaults\n" port)
> >
> > Correct me if I'm wrong, but was "BeginDefaults" not the method of choice
> > to say: if no other value is given, please take A4 instead of that
> > awkward Letter format?
>
> No, that's not what it is at all. You may find it instructive to refer
> to the specification.
> http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf     

Thanks for the clarification.

> > And BTW, Lily's PostScript code's main purpose is to produce something
> > which Ghostscript turns into a PDF. So, the PostScript does not have to
> > adher strictly to the specs, but to what Ghostscript understands.
>
> Yikes, really!? That's good to know, I guess, but also kind of
> disappointing.  For some reason that I have not bothered to debug,
> PDFs that LilyPond (2.6.3) generates for me have bizarre defects, like
> all text turning into the letter "y," etc. As such, postscript is the
> way to go. Not to mention that it's faster.

If I sounded like your work was not valuable, I made myself misunderstood.
It sure would be a fine thing if the PostScript could be sent to a
PostScript printer without problems.

Ciao,
Dscho



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

Han-Wen Nienhuys-3
In reply to this post by John Hawkinson
The changes were made with hints from the GSview author, with the primary purpose of making GSview grok the code. I readily admit that my postscript knowledge is virtually nonexistent. Feel free to submit patches to make lily create sane PS.

2006/4/16, John Hawkinson [hidden email]:
> And BTW, Lily's PostScript code's main purpose is to produce something
> which Ghostscript turns into a PDF. So, the PostScript does not have to
> adher strictly to the specs, but to what Ghostscript understands.

Yikes, really!? That's good to know, I guess, but also kind of
disappointing.  For some reason that I have not bothered to debug,
PDFs that LilyPond (2.6.3) generates for me have bizarre defects, like
all text turning into the letter "y," etc. As such, postscript is the
way to go. Not to mention that it's faster.


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
 


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Whither the switch to OpenType fonts? (they break my printer)

John Hawkinson
In reply to this post by John Hawkinson
I mentioned in a separate thread ("Why is %%PageMedia: a4 hardcoded?")
some problems with LilyPond's Postscript hanging my printer (as of
2.7.38 and later; 2.7.36 and prior worked fine).

At first, I presumed that this was a result of having a potentially
non-8-bit clean path to my printer because of site-local spooling
system issues, but I've verified that's not the case (spooling files
to the printer directly with netcat, etc.).

It seems that the binary OTF encodings of both Aybabtu-Regular and
Emmentaler-18 give this problem. Going and hand-editing the postscript
and replacing the OTF versions with the type1 versions (and renaming
the references to the fonts from Aybabtu-Regular to
PFAAybabtu-Regular, etc.,) produces a file that works fine (though it
is 26% larger).

How does it crash the printer? Well, various ways. Most clearly is
that sometimes it produces a 79.00FE crash on the front panel, and
other times it simply hangs the printer such that it does not respond
to input over the network or on the front panel. I haven't pursued it
with HP, but they do have a history of having a myriad of such
problems with strange binary encodings. The printer in question is an
HP8150DN (of which we have a whole slew around here) running the most
recent firmware (20041013 MB7.119).

One workaround I tried was to convert the fonts to hex, and wrap their
encoding in:
        currentfile /ASCIIHexDecode filter cvx exec
        %...hex of the font here...
        >

This does not work. It seems to work for Aybabtu, but not for
Emmentaler, which causes an error even with ghostscript. (Error:
/invalidfont in --.type42execchar--) I'm not sure why...

So anyhow:

. Can LilyPond go back to Type 1 fonts in the interest of
        broader compatibility? Or perhaps this could be an option (but
        they would have to be generated at build time, anyhow). On the
        other hand, is there anything to be gained by OTF fonts?
        having the PS files a bit smaller probably doesn't matter for
        the ghostscript ps->pdf conversion, and doesn't seem a big price
        to pay for better compatibility.

. Why do the different encodings (Type1 PFA, OTF) produce
        differing-named fonts (PFAAybabtu-Regular vs. Aybabtu-Regular)?
        [hence the necessity for munge-lily-font-name].

It seems like this has potentially been a problem before.
Revs 1.84 through 1.86 of scm/framework-ps.scm share this log message
tidbit:

* scm/framework-ps.scm (munge-lily-font-name): new function
(write-preamble): hack: insert PFA equivalent of CFF into
.PS. This makes LilyPond output printable on normal PS printers
again.


I suppose that I could attempt to take up this issue with HP,
and perhaps get it fixed in a new firmware version half a year
from now (not that they've released any in the past 2 years),
but I must say I'm not enthusiastic.


In that other thread, <[hidden email]> wrote on Mon, 17
Apr 2006 at 13:14:03 +0200 in
<[hidden email]>:

> It sure would be a fine thing if the PostScript could be sent to a
> PostScript printer without problems.

Great!

--jhawk


John Hawkinson <[hidden email]> wrote on Sun, 16 Apr 2006
at 21:34:22 -0400 in <[hidden email]>:

> Date: Sun, 16 Apr 2006 21:34:22 -0400
> From: John Hawkinson <[hidden email]>
> To: [hidden email]
> Message-ID: <[hidden email]>
> In-Reply-To: <[hidden email]>
> Subject: Re: Why is %%PageMedia: a4 hardcoded?
>
> I <[hidden email]> wrote (quite a few hours ago...) on Sun, 16 Apr 2006
> at 10:55:43 -0400 in <[hidden email]>:
>
> > p.s.: In moving from LilyPond 2.6.3 to 2.9.2, I find that spooling
> > postscript crashes my HP LaserJet 8150DN.  Haven't finished
> > figuring out why yet... I'll get there...
>
> It appears that this broke between 2.7.36 and 2.7.38,
> and it seems to be a result of the massive font changes
> that happened therein (apparently moving to embedding
> opentype fonts instead of Type 1 fonts?).
>
> I can't seem to find a discussion of the rationale for all of this on
> lilypond-{user,devel} or bug-lilypond. Am I just missing it, or could
> someone point me to the discussion?
>
>
> Perhaps it has something to do with my print spooling environment, but
> it seems like the non-eight-bit-clean nature of the generated
> PostScript is likely to be my problem...
>
> Thanks for any pointers...
>
> --jhawk
>
>
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/lilypond-devel


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why is %%PageMedia: a4 hardcoded?

Pedro Kröger
In reply to this post by Han-Wen Nienhuys-3
"Han-Wen Nienhuys" <[hidden email]> writes:

> all text turning into the letter "y," etc. As such, postscript is the
> way to go. Not to mention that it's faster.

not to mention that with postscript the user can have an open reader
that will be automatically re-draw after each lilypond rendering. (I
mean, the 'watch file' in gv)

pedro


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Whither the switch to OpenType fonts? (they break my printer)

Han-Wen Nienhuys-3
In reply to this post by John Hawkinson

2006/4/17, John Hawkinson <[hidden email]>:

How does it crash the printer? Well, various ways. Most clearly is
that sometimes it produces a 79.00FE crash on the front panel, and
other times it simply hangs the printer such that it does not respond
to input over the network or on the front panel. I haven't pursued it
with HP, but they do have a history of having a myriad of such
problems with strange binary encodings. The printer in question is an
HP8150DN (of which we have a whole slew around here) running the most
recent firmware (20041013 MB7.119).

One workaround I tried was to convert the fonts to hex, and wrap their
encoding in:
        currentfile /ASCIIHexDecode filter cvx exec
        %...hex of the font here...
        >

This does not work. It seems to work for Aybabtu, but not for
Emmentaler, which causes an error even with ghostscript. (Error:
/invalidfont in --.type42execchar--) I'm not sure why...

I'd gladly have a patch for ascii-wrapping the OTF binary, because inserting binary data in PS doesn't give me good vibes.  If this is valid PS, we should take the issue up with ghostscript development.
 

So anyhow:

.       Can LilyPond go back to Type 1 fonts in the interest of
        broader compatibility? Or perhaps this could be an option (but
        they would have to be generated at build time, anyhow). On the
        other hand, is there anything to be gained by OTF fonts?
        having the PS files a bit smaller probably doesn't matter for
        the ghostscript ps->pdf conversion, and doesn't seem a big price
        to pay for better compatibility.
.       Why do the different encodings (Type1 PFA, OTF) produce
        differing-named fonts (PFAAybabtu-Regular vs. Aybabtu-Regular)?
        [hence the necessity for munge-lily-font-name].

The problem is that FontConfig will see different versions of the same font, and it can get confused and pick the wrong font. Also, the whole machinery for creating the PFAFoo fonts, detecting when to substitute them and finding them on disk is ugly and rather fragile. We've had  a lot of bugs relating to it.  We're using an OTF font iso. a Type1 font because we have to store various extra parameters inside the font. OTF/TTF has a neat mechanism for that, which Type1 lacks.

Of course, if we can make our PS more conforming, I'm all for it, but I'm opposed to  (re)installing hacks for being compatible with broken hardware.  

It seems like this has potentially been a problem before.
Revs 1.84 through 1.86 of scm/framework-ps.scm share this log message
tidbit:

* scm/framework-ps.scm (munge-lily-font-name): new function
(write-preamble): hack: insert PFA equivalent of CFF into
.PS. This makes LilyPond output printable on normal PS printers
again.

Could very well be; I also have an HP printer (LJ2100 with a PS dimm). However, the reason for installing the hack was related to a Ghostscript bug. We reverted the hack because the bug has been fixed now.

I suppose that I could attempt to take up this issue with HP,
and perhaps get it fixed in a new firmware version half a year
from now (not that they've released any in the past 2 years),
but I must say I'm not enthusiastic.


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Whither the switch to OpenType fonts? (they break my printer)

John Hawkinson
Han-Wen Nienhuys <[hidden email]> wrote on Thu, 20 Apr 2006
at 16:49:04 -0300 in <[hidden email]>:

> I'd gladly have a patch for ascii-wrapping the OTF binary, because inserting
> binary data in PS doesn't give me good vibes.  If this is valid PS, we
> should take the issue up with ghostscript development.

I think it is valid, but it doesn't work on my printer either :(
So I'm not sure it's an issue worth pursuing.
It does work for non-weird postscript, just not for these fonts...

> > Revs 1.84 through 1.86 of scm/framework-ps.scm share this log message
> > tidbit:
> >
> > * scm/framework-ps.scm (munge-lily-font-name): new function
> > (write-preamble): hack: insert PFA equivalent of CFF into
> > .PS. This makes LilyPond output printable on normal PS printers
> > again.
>
>
> Could very well be; I also have an HP printer (LJ2100 with a PS dimm).
> However, the reason for installing the hack was related to a Ghostscript
> bug.

Err...the text there is your text from the log message, not mine :)

> We reverted the hack because the bug has been fixed now.

I'm really confused, since your log message (presumably written by you?)
says that it was necessary for printing on normal PS printers.
Empirically that seems to be the case as well.

--jhawk


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Whither the switch to OpenType fonts? (they break my printer)

John Hawkinson
(Quoting Han-Wen)
> yeah, I meant to quote the bit about buggy HP PS drivers

Ah.

I'm not sure what to do from here then. You said before:

> Of course, if we can make our PS more conforming, I'm all for it, but I'm
> opposed to  (re)installing hacks for being compatible with broken hardware.

While I agree in principle, it seems like we should go to some effort
to produce postscript that works in most places. ("Be liberal in what
you accept and conservative in what you send.") There have been recent
complaints that LilyPond's postscript breaks various other
applications as well, and I suspect that this is the reason.

It is generally the case that some significant set of environments
seem to have trouble with binary-laden PostScript, though I think
this is not the problem here (because of wrapping it in a hex
filter fails).

I have to wonder, then if there is not some subtle bug in fontforge's
Type42 encoding that is making these HP printers die. I don't claim
that HP has a rock solid PS implementation, but most of the time it is
pretty decent.

> The problem is that FontConfig will see different versions of the same font,
> and it can get confused and pick the wrong font. Also, the whole machinery
> for creating the PFAFoo fonts, detecting when to substitute them and finding
> them on disk is ugly and rather fragile. We've had  a lot of bugs relating
> to it.

OK. This part really isn't a big deal, of course... Just an issue for
the humans reading the PS code and editing by hand (why would anyone
do that? :)).

> We're using an OTF font iso. a Type1 font because we have to store
> various extra parameters inside the font. OTF/TTF has a neat mechanism for
> that, which Type1 lacks.

I'm a bit confused, then. How is is it that you don't lose functionality
by using the OTF font?

It seems like the Type1 font is always going to be more portable.


My preference would be to restore the use of Type1, if only as an option.

--jhawk


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Whither the switch to OpenType fonts? (they break my printer)

Han-Wen Nienhuys-3


2006/4/20, John Hawkinson <[hidden email]>:
I have to wonder, then if there is not some subtle bug in fontforge's
Type42 encoding that is making these HP printers die. I don't claim
that HP has a rock solid PS implementation, but most of the time it is
pretty decent.


that's very well possible. FF is in continuous development, and bugs creep up quite often. Fortunately, they get fixed very soon too.


> The problem is that FontConfig will see different versions of the same font,
> and it can get confused and pick the wrong font. Also, the whole machinery
> for creating the PFAFoo fonts, detecting when to substitute them and finding
> them on disk is ugly and rather fragile. We've had  a lot of bugs relating
> to it.

OK. This part really isn't a big deal, of course... Just an issue for

i'm not referring to hand-editing the PS, but rather to getting stencils specced for OTF fonts from the lily formatting engine and then substituting type1 fonts (but only sometimes) fonts.
 
> We're using an OTF font iso. a Type1 font because we have to store
> various extra parameters inside the font. OTF/TTF has a neat mechanism for
> that, which Type1 lacks.

I'm a bit confused, then. How is is it that you don't lose functionality
by using the OTF font?

It seems like the Type1 font is always going to be more portable.

Yes, but I don't want to add a fix for a futher undiagnosed problem just because the fix happens to work. I want to solve the root cause, not fix symptoms. How can we check that Lily's output conforms to the PS spec to the letter?
 

_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel