Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043 by karlinh...@gmail.com)

[David Nalesnik]

Hi Karlin,

On Fri, Sep 22, 2017 at 5:29 PM, Karlin High  wrote:
> On Fri, Sep 22, 2017 at 2:37 PM, Karlin High  wrote:
>> All right, I'm giving up and asking for help.
>
> I got good help from Carl Sorenson; thanks! Changed patch for review,
> now contains both code and documentation.
> --

Glad you got this squared away!  Just for reference you might look at
the email I got when I had a similar problem myself:

https://www.mail-archive.com/lilypond-devel@gnu.org/msg51407.html

Best,
David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043 by karlinh...@gmail.com)

[Karlin High]

On Fri, Sep 22, 2017 at 5:46 PM, Thomas Morley  wrote:
> Hi Karlin,
>
> at the time I started using git I was pointed to
> https://git-scm.com/book/en/v2
>
> Served me well (and still does)
>
> Cheers,
>   Harm

Thanks for the reference! I started reading that (or a prior version)
a year or three ago. Sometimes I have trouble absorbing information
before encountering a need for it - use it or lose it, I'm afraid.
Before this, I haven't had projects that exceeded the version-control
abilities of the "Save As" command - with git I'm still in the mode of
xkcd.com/1597. But digging around in the LilyPond source code gives me
a feeling similar to looking up at the General Sherman Tree. I can see
that git is vital to projects like this.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043 by karlinh...@gmail.com)

[Thomas Morley]

2017-09-23 0:29 GMT+02:00 Karlin High :
> On Fri, Sep 22, 2017 at 2:37 PM, Karlin High  wrote:
>> All right, I'm giving up and asking for help.
>
> I got good help from Carl Sorenson; thanks! Changed patch for review,
> now contains both code and documentation.
> --
> Karlin High
> Missouri, USA



Hi Karlin,

at the time I started using git I was pointed to
https://git-scm.com/book/en/v2

Served me well (and still does)

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043 by karlinh...@gmail.com)

[Karlin High]

On Fri, Sep 22, 2017 at 2:37 PM, Karlin High  wrote:
> All right, I'm giving up and asking for help.

I got good help from Carl Sorenson; thanks! Changed patch for review,
now contains both code and documentation.
--
Karlin High
Missouri, USA

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043 by karlinh...@gmail.com)

[Karlin High]

On Thu, Sep 21, 2017 at 9:28 AM,   wrote:
> Literally, just add one line of code to the example in Shape Note Heads,
> in NR 1.1.4., that uses
> either \aikenThinHeads or \aikenThinHeadsMinor (no need to include
> both).  No change in the text
> is necessary.
>
> All we want is a single demonstration of the command, not an exhaustive
> demonstration.
> The documentation policy is to show, don't tell, and to remove as much
> as possible.  We
> assume the reader to be intelligent and able to extrapolate from given
> examples.  The NR is,
> by design, NOT a tutorial.
>
> Literally, I think you should add two lines to the example -- one line
> for the \aikenThinHeads,
> and one line that is a duplicate of the scale shown for all of the other
> heads.
>
> THanks,
>
> Carl
>
> https://codereview.appspot.com/326510043/


All right, I'm giving up and asking for help. I'm attaching the patch
I tried to git-cl up to Rietveld, and it picked up lots of other
things from I believe the git pull -r I did just prior. I went to
Rietveld and deleted it.

Now, to get just this patch uploaded -- was I supposed to make a new
local branch first?
--
Karlin High
Missouri, USA
(aka "The Show-Me State")
From 633117b0e12e85286fc84d61e3b28e3c26591a81 Mon Sep 17 00:00:00 2001
From: Karlin High 
Date: Fri, 22 Sep 2017 13:39:35 -0500
Subject: [PATCH 2/2] DOC: NR 1.1.4 Shape Note Heads, Issue 5187 Add Thin Aiken
 note heads

This issue adds a command for a note head style.
Here the documentation for note heads is updated for the new style.
---
 Documentation/notation/pitches.itely | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/notation/pitches.itely b/Documentation/notation/pitches.itely
index d7fcd4d..3271016 100644
--- a/Documentation/notation/pitches.itely
+++ b/Documentation/notation/pitches.itely
@@ -3260,6 +3260,7 @@ Internals Reference:
 @cindex note heads, Walker
 
 @funindex \aikenHeads
+@funindex \aikenThinHeads
 @funindex \sacredHarpHeads
 @funindex \southernHarmonyHeads
 @funindex \funkHeads
@@ -3275,6 +3276,8 @@ Funk (Harmonica Sacra), Walker, and Aiken (Christian Harmony) styles:
 \relative c'' {
   \aikenHeads
   c, d e f g2 a b1 c \break
+  \aikenThinHeads
+  c,4 d e f g2 a b1 c \break
   \sacredHarpHeads
   c,4 d e f g2 a b1 c \break
   \southernHarmonyHeads
@@ -3288,6 +3291,7 @@ Funk (Harmonica Sacra), Walker, and Aiken (Christian Harmony) styles:
 
 @funindex \key
 @funindex \aikenHeadsMinor
+@funindex \aikenThinHeadsMinor
 @funindex \sacredHarpHeadsMinor
 @funindex \southernHarmonyHeadsMinor
 @funindex \funkHeadsMinor
@@ -3305,6 +3309,8 @@ major:
   a b c d e2 f g1 a \break
   \aikenHeadsMinor
   a,4 b c d e2 f g1 a \break
+  \aikenThinHeadsMinor
+  a,4 b c d e2 f g1 a \break
   \sacredHarpHeadsMinor
   a,2 b c d \break
   \southernHarmonyHeadsMinor
@@ -3320,6 +3326,8 @@ major:
 @predefined
 @code{\aikenHeads},
 @code{\aikenHeadsMinor},
+@code{\aikenThinHeads},
+@code{\aikenThinHeadsMinor},
 @code{\funkHeads},
 @code{\funkHeadsMinor},
 @code{\sacredHarpHeads},
-- 
2.1.4

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

[Masamichi Hosoda]

This discussion concerns two mailing lists,
some mails exist in both archives,
but other mail seems to exist only in one archive.
For convenience of people subscribing to only one mailing list,
both mailing list archive URLs are as follows.

http://lists.gnu.org/archive/html/lilypond-devel/2017-09/index.html
https://ghostscript.com/pipermail/gs-devel/2017-September/date.html

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

[Masamichi Hosoda]

> In my impression, if
> 
> $ gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
> -r1200
> -dSubsetFonts=false -sDEVICE=pdfwrite -dAutoRotatePages=/None
> -sOutputFile=filename.pdf -c.setpdfwrite -ffilename.eps
> 
> does not embed the completed font into PDF, Ghostscript developers
> would
> regard it as a bug and they might be willing to fix it (at least, try
> to
> fix it).
> 
> Could you provide some sample EPS files to reproduce the issue,
> and the resulted PDF in your environment?

Here is sample files `20170922_lilypond_eps_pdf_examples.tar.xz`
https://drive.google.com/file/d/0ByGBX3PDrqjsSFhVdXJfbjFjRlk/view?usp=sharing

It contains `README.md`.
Would you read the file?

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Masamichi Hosoda]

>>If there is a full font embedded (non-subset) PDF,
>>does the bigpdfs trick work effectively?
> 
> Its still, in my opinion, a risky thing to do. However, if the font
> were fully embedded, you wouldn't need to use Ghostscript and the
> PDFDontUseFontObjectNum bug approach (which is the risky part).
> 
> Because the fonts would be genuinely identical, MuPDF would be able to
> spot the font streams at least as being the same and would be able to
> reliably remove the duplicates.
> 
> The Font and FontDescriptor dictionaries might not be possible to
> remove, so the effect wouldn't be quite as good as the current
> approach, but these dictionaries run to a few tens or at most a few
> hundred bytes. The FontFile streams are where most of the space is
> going, and those would be possible to remove, if they were truly
> duplicates.

I understand that the bigpdfs trick should to be fixed
to use MuPDF instead of PDFDontUseFontObjectNum bug.

>>Or, even so, should we take other methods (e.g. using non-embedded
>>PDFs)?
> 
> I'm not sure what other methods there would be. Using EPS inclusions
> would have the same effect as PDF. Rendering to bitmaps would be (I'd
> guess) as large as the PDF files, and would suffer from
> non-scalability.
> 
> Converting to TeX format would probably work, but apparently there
> were problems with that.
> 
> Is there some other approach available ?

There is a method of using font non-embedded PDF.
In my experiment, it seems to work fine except TrueType fonts.

It uses like
`-c ".setpdfwrite << /NeverEmbed [ /Emmentaler-20 /TeXGyreSchola-Regular ] >> 
setdistillerparams"`
instead of
`-sOutputFile=filename.pdf`.

I've made sample files `20170922_lilypond_eps_pdf_examples.tar.xz`.
https://drive.google.com/file/d/0ByGBX3PDrqjsSFhVdXJfbjFjRlk/view?usp=sharing

In the tarball:

`fonts?-bigpdfs.eps`: EPS that is generated by LilyPond.
`fonts?-bigpdfs-noembed.pdf`: No font embedded PDF
  that is generated by Ghostscript
  with `/NeverEmbed` parameter like above.
`include-bigpdfs-noembed.pdf`: TeX outputted PDF that lacks LilyPond fonts.
`include-bigpdfs-noembed-gse.pdf`: Finally PDF that is font embedded
   by Ghostscript.

In `include-bigpdfs-noembed-gse.pdf`,
OTF seems to be fine. However, some glyphs of TTF are broken.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fwd: You Made Our List: The 50 Best Music Tools Online

[David Kastrup]

Han-Wen Nienhuys  writes:

> -- Forwarded message --
> From: Jason OConnor 
> Date: Fri, Sep 22, 2017 at 3:47 PM
> Subject: You Made Our List: The 50 Best Music Tools Online
> To: "han...@xs4all.nl" 
>
>
> 
>
> Hi Han-Wen Nienhuys,
>
> I wanted to let you know that LilyPond made our list of *The 50 Best Music
> Tools Online .*
> Congratulations.
>
> We spent a lot of time coming up with this list and many great music tools
> were considered, so you ought to be proud!

Well, they did not include Ardour.  That's sort of a puzzler since there
is not much of an alternative if you are looking for free software in
the DAW area.

> We hope this gives you a bit more exposure (and it's always good to
> get a third-party endorsement!)

Well, the exposure is a bit limited, given that their list is not
accessible from their home page and is not even listed on their site
map.

I am somewhat afraid that at least currently this does not look like
much more than astroturfing.  Even so, we made it to the first 50
targets of this particular compaign (given that it's not linked to
anywhere, it is hard to guess how many others there might be).

But then there is actually hardly a list of free (as opposed to gratis)
software for musicians where LilyPond isn't mentioned.  So while I am
not especially thrilled about this particular honor, that doesn't mean
that I don't consider LilyPond to be in high public standing.

All the best

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Fwd: You Made Our List: The 50 Best Music Tools Online

[Han-Wen Nienhuys]

-- Forwarded message --
From: Jason OConnor 
Date: Fri, Sep 22, 2017 at 3:47 PM
Subject: You Made Our List: The 50 Best Music Tools Online
To: "han...@xs4all.nl" 




Hi Han-Wen Nienhuys,

I wanted to let you know that LilyPond made our list of *The 50 Best Music
Tools Online .*
Congratulations.

We spent a lot of time coming up with this list and many great music tools
were considered, so you ought to be proud!

We hope this gives you a bit more exposure (and it's always good to get a
third-party endorsement!)

You can see your listing and the 49 other ones that made our list here:
http://www.clickitticket.com/best-online-music-tools/



All the Best,

Jason OConnor

ClickitTicket.com 




P.S. I am a musician, that's me in the picture above with my fretless bass,
so you can feel confident this is a good list!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alpha transparency to SVG backend (issue 330300043 by beauleetien...@gmail.com)

[beauleetienne0]

On 2017/09/22 11:34:30, dak wrote:

On 2017/09/22 11:19:08, Ebe123 wrote:
> Add to regression tests



I think it is a bad idea to change rgb-color here: this is a recipe

for

wide-reaching incompatibilities for the sake of limited applications.

It would

make more sense to meddle with the type of the "transparent" property,

making it

a boolean-or-number? for example.



If transparency is supposed to be made into a part of color, I think

it should

rather be optional: see
 for a

proposal in

that regard.



However, I think that transparency is really something that tends to

have

considerably different scope and application as color and is more

often than not

applied in manners orthogonal to color, so keeping it in a separate

property

might make for a lot less conflicts of use cases in the long run.


So [#5189] would be preferable to this. There would be way more work if
done that way. Alpha transparency is integrated with color in some
formats, such as SVG. Here, if using rgb-color, the opacity is optional
as it defaults to 1,0. There is also a convert-ly rule for changing rgb-
to rgba-.

https://codereview.appspot.com/330300043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alpha transparency to SVG backend (issue 330300043 by beauleetien...@gmail.com)

[dak]

On 2017/09/22 11:19:08, Ebe123 wrote:

Add to regression tests


I think it is a bad idea to change rgb-color here: this is a recipe for
wide-reaching incompatibilities for the sake of limited applications.
It would make more sense to meddle with the type of the "transparent"
property, making it a boolean-or-number? for example.

If transparency is supposed to be made into a part of color, I think it
should rather be optional: see
 for a
proposal in that regard.

However, I think that transparency is really something that tends to
have considerably different scope and application as color and is more
often than not applied in manners orthogonal to color, so keeping it in
a separate property might make for a lot less conflicts of use cases in
the long run.

https://codereview.appspot.com/330300043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Ken Sharp]

At 10:12 22/09/2017 +0200, David Kastrup wrote:



Well, if we could delay the embedding, I'd not be particularly sad:
"make doc" currently(?) eats up more than 3Gb which is sort of
ridiculous.  The intermediate PDFs for lilypond-book are arranged in
some "database" and not really externalized, so if they don't work on
their own, this isn't a showstopper.


I guessed this was the case, and that's what I was aiming for, sadly it 
doesn't work.




At any rate, any such strategy could not be implemented and tested in
short time, so if in the mean time the font merging expedient would stay
available for some time, it would make things a lot smoother for us.


Clearly it'll have to, whatever happens next. There simply isn't time to 
implement and test anything else. And I'd be very nervous about putting any 
changes into the release without a decent interval for bugs to emerge.




We are not really striving for "optimum" rather than "better than awful"
regarding the resulting file sizes.  This seems like being close enough.


Again I guessed this was probably the case, but its good to hear it for 
sure. As I said in reply to suzuki toshiya, if the font isn't being fully 
embedded I'd be inclined to regard that as a bug (slightly diffident as I 
don't even know *why* its not being fully embedded yet, there might be a 
good reason).


If the font(s) were fully embedded, then mutool could remove the duplicates 
from the final file. Caveat; the intermediate PDF files will be bigger, 
possibly a *lot* bigger. Currently the font streams are running at ~9KB, 
the full font is ~65KB uncompressed, lets say 30 KB compressed (CFF fonts 
don't compress well). So you're looking at each file growing by about 40KB. 
If the 3xfont embedding I see in 9.22 is real, then that becomes 100KB, 
maybe more if its one font per character.


I'm sorry to keep repeating but I do need to take a good chunk of time to 
look into this, which I don't have right now.


I need to see why the font isn't being fully embedded, and why 9.22 is 
apparently embedding multiple fonts when I'd only expect one. The text and 
font code is particularly difficult to debug and amend, so this is probably 
several weeks work.



Ken


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Ken Sharp]

At 10:23 22/09/2017 +0200, David Kastrup wrote:


If it's a conceivable part of a good longterm strategy: I think our
fonts are generated via Fontforge starting with a METAFONT (or
METAPOST?) font description, so it's conceivable that if other font
formats would generally be better supported by toolchains in general
that we could possibly tell Fontforge to generate other formats.

I have very little clue of what is involved here, and circumnavigating a
possibly temporary Ghostscript bug alone would likely not be enough of
an incentive for investing that work.  It would really depend on the
quality of general support (mostly in the Free Software world) that we
could count on whether format/technology changes make sense here.


I think the most important thing is for me to get a grip on what's actually 
going on. I believe we intend to improve support for OTF fonts as 
substitutes for missing Fonts, but that's a long term project, so it only 
gets worked on when there are free cycles (and not by me any more) so 
eventually that problem may go away.


But there's no reason to wait for that, it was only a possible way to solve 
a problem. Looking at the real problems, potentially bugs, that I see is 
probably more important and more productive.




Ken


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[David Kastrup]

Ken Sharp  writes:

> At 00:41 22/09/2017 +0200, David Kastrup wrote:
>
>
>> > Or, even so, should we take other methods (e.g. using non-embedded PDFs)?
>>
>>If we figure out a working alternative, we should take it.  The current
>>set of Ghostscript bugs in 9.22 is still a bit in flux, so it's not
>>clear yet which alternative actually could work.
>>
>>Is that a reasonable summary of the current state, Ken?
>
> I'd say so, yes. I can't think of a reasonable alternative right at
> the moment, which will yield the same or at least similar output file
> size.

[...]

> I've no idea why they aren't fully embedded but I'd have to guess its
> because they are CFF outlines, we don't see a lot of those. So it
> smells like a bug. I will look at it, as soon as I get some time, but
> its not likely to be a change we'll put into 9.22 given the state of
> the release cycle. In fact, realistically, its unlikely I'll even get
> the time to look at it before the release is complete.

If it's a conceivable part of a good longterm strategy: I think our
fonts are generated via Fontforge starting with a METAFONT (or
METAPOST?) font description, so it's conceivable that if other font
formats would generally be better supported by toolchains in general
that we could possibly tell Fontforge to generate other formats.

I have very little clue of what is involved here, and circumnavigating a
possibly temporary Ghostscript bug alone would likely not be enough of
an incentive for investing that work.  It would really depend on the
quality of general support (mostly in the Free Software world) that we
could count on whether format/technology changes make sense here.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[David Kastrup]

Ken Sharp  writes:

> At 07:01 22/09/2017 +0900, Masamichi Hosoda wrote:
>
>>If there is a full font embedded (non-subset) PDF,
>>does the bigpdfs trick work effectively?
>
> Its still, in my opinion, a risky thing to do. However, if the font
> were fully embedded, you wouldn't need to use Ghostscript and the
> PDFDontUseFontObjectNum bug approach (which is the risky part).

Well, if we could delay the embedding, I'd not be particularly sad:
"make doc" currently(?) eats up more than 3Gb which is sort of
ridiculous.  The intermediate PDFs for lilypond-book are arranged in
some "database" and not really externalized, so if they don't work on
their own, this isn't a showstopper.  Generating the images is usually
done by a limited number of LilyPond jobs (depending on the number of
processors available), each of them converting hundreds of input files
into corresponding PDF files.  It would be conceivable to at least keep
some sort of font identifier consistent in a single job.  Embedding a
font 10 times (for 10 graphics-generating jobs) seems at least better
than embedding it hundreds of times.

At any rate, any such strategy could not be implemented and tested in
short time, so if in the mean time the font merging expedient would stay
available for some time, it would make things a lot smoother for us.

> The Font and FontDescriptor dictionaries might not be possible to
> remove, so the effect wouldn't be quite as good as the current
> approach, but these dictionaries run to a few tens or at most a few
> hundred bytes. The FontFile streams are where most of the space is
> going, and those would be possible to remove, if they were truly
> duplicates.

We are not really striving for "optimum" rather than "better than awful"
regarding the resulting file sizes.  This seems like being close enough.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Ken Sharp]

At 00:41 22/09/2017 +0200, David Kastrup wrote:



> Or, even so, should we take other methods (e.g. using non-embedded PDFs)?

If we figure out a working alternative, we should take it.  The current
set of Ghostscript bugs in 9.22 is still a bit in flux, so it's not
clear yet which alternative actually could work.

Is that a reasonable summary of the current state, Ken?


I'd say so, yes. I can't think of a reasonable alternative right at the 
moment, which will yield the same or at least similar output file size. 
Especially given the time scale of our ongoing release. The only other 
approach I could think of didn't work. If someone has other ideas I'll be 
happy to try them out or at least think them over.


As I said in my reply (sorry I saw Masamichi's mail first and replied to it 
first), *if* the fonts were fully embedded which, from a first glance they 
should be, then you wouldn't need this trickery. You could just use MuPDF 
to remove the duplicated FontFile objects, because they'd really be identical.


I've no idea why they aren't fully embedded but I'd have to guess its 
because they are CFF outlines, we don't see a lot of those. So it smells 
like a bug. I will look at it, as soon as I get some time, but its not 
likely to be a change we'll put into 9.22 given the state of the release 
cycle. In fact, realistically, its unlikely I'll even get the time to look 
at it before the release is complete.


So this is something that probably needs to be looked at after the release, 
preferably at leisure. Time pressure sort of makes this a lot worse.


More worrying is the fact that when I run the EPS files here with the 
current release candidate, I don't get one copy of Emmentaler-20 in the 
output PDF files, I get three. For me that didn't make any difference in 
the final output file, but it is a concern because I don't know why that 
would have changed.



Ken


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Ken Sharp]

At 07:01 22/09/2017 +0900, Masamichi Hosoda wrote:


If there is a full font embedded (non-subset) PDF,
does the bigpdfs trick work effectively?


Its still, in my opinion, a risky thing to do. However, if the font were 
fully embedded, you wouldn't need to use Ghostscript and the 
PDFDontUseFontObjectNum bug approach (which is the risky part).


Because the fonts would be genuinely identical, MuPDF would be able to spot 
the font streams at least as being the same and would be able to reliably 
remove the duplicates.


The Font and FontDescriptor dictionaries might not be possible to remove, 
so the effect wouldn't be quite as good as the current approach, but these 
dictionaries run to a few tens or at most a few hundred bytes. The FontFile 
streams are where most of the space is going, and those would be possible 
to remove, if they were truly duplicates.




Or, even so, should we take other methods (e.g. using non-embedded PDFs)?


I'm not sure what other methods there would be. Using EPS inclusions would 
have the same effect as PDF. Rendering to bitmaps would be (I'd guess) as 
large as the PDF files, and would suffer from non-scalability.


Converting to TeX format would probably work, but apparently there were 
problems with that.


Is there some other approach available ?


Ken


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel