Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[knupero]

Combining them means that the size of the final PDF may be smaller but

the size

of the intermediate PDFs will be larger.
In my experiment, even if there is a bug in gs's full set font

embedding, the

disk size that `make doc` eats has increased.


I did not check that, but I would expect an increase in disk usage for
the build.


If I understand correctly, `--bigpdfs` / `-b` has two effects.
One is to embed full set (non-subset) font.
The other is to define and use some encodings for Emmentaler.


It also changes the way emmentaler glyphs are printed. With --bigpdfs we
use the "show" postscript operator, without it we still use "glyphshow".
And the three emmentaler fonts for every size in the intermediate
versions of our pdfs are not 3 copies of the full emmentaler-xx font but
are three different fonts made of emmentaler-xx glyphs. Those subsets
must not be further subsetted.

No, it is senseless to split -b into separate options.

https://codereview.appspot.com/325630043/

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

Re: midi2ly on mac: midi.so wrong architecture

[David Kastrup]

Graham Percival  writes:

> On Fri, Jul 28, 2017 at 08:01:06AM +0200, David Kastrup wrote:
>> ElRay  writes:
>> 
>> > FYI:  This has been reported as a bug -- in 2012.I will see if this is
>> > something I can take-on in the next month or two.
>> 
>> I am pretty sure that Graham posted a patch for this on one of the lists
>> one of the last times this was being discussed.
>
> The patch was accepted in 2.19.55, and midi.c was removed:
> d8677d345032752b564878e5da0ea17b112afcad
> 37893d923c65a5f1aec6c78f7225704d2ccec666
>
> That said, the 2.18.2 release was (obviously) not updated, so
> anybody using the stable release would still see the same error.

Doh.

The original report specified "2.19.15" in its \version statement.  If
that was somewhat related to the actual version used, it would fully
explain the problem.

-- 
David Kastrup

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

PATCHES - Countdown for Saturday September 23rd

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on 
September 26th


A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/




Push:


5197 Include direction marker in post-event location - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5197
http://codereview.appspot.com/328660043


5194 Improve warning for unattached post-event(s) - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5194
http://codereview.appspot.com/328630043


Countdown: No patches in countdown at this time.


Review:


5201 Use -b together with -dgs-never-embed-fonts - Knut Petersen
https://sourceforge.net/p/testlilyissues/issues/5201
http://codereview.appspot.com/325630043

5200 display-lily-tests.ly: Remove unused lily-string->markup - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5200
http://codereview.appspot.com/324490043

5198 Add command for Thin Aiken noteheads - Karlin High
https://sourceforge.net/p/testlilyissues/issues/5198
http://codereview.appspot.com/326510043

5176 2.20 - re-organize Changes.tely into Topics - James Lowe
https://sourceforge.net/p/testlilyissues/issues/5176
http://codereview.appspot.com/326400043


New: no New patches at this time


Waiting:

4603 change all occurences of ‘partcombine’ to ‘partCombine’. - James Lowe
https://sourceforge.net/p/testlilyissues/issues/4603
http://codereview.appspot.com/323040043



Regards

James

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

Re: midi2ly on mac: midi.so wrong architecture

[Graham Percival]

On Fri, Jul 28, 2017 at 08:01:06AM +0200, David Kastrup wrote:
> ElRay  writes:
> 
> > FYI:  This has been reported as a bug -- in 2012.I will see if this is
> > something I can take-on in the next month or two.
> 
> I am pretty sure that Graham posted a patch for this on one of the lists
> one of the last times this was being discussed.

The patch was accepted in 2.19.55, and midi.c was removed:
d8677d345032752b564878e5da0ea17b112afcad
37893d923c65a5f1aec6c78f7225704d2ccec666

That said, the 2.18.2 release was (obviously) not updated, so
anybody using the stable release would still see the same error.

Cheers,
- Graham

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

display-lily-tests.ly: Remove unused lily-string->markup (issue 324490043 by d...@gnu.org)

[thomasmorley65]

LGTM

https://codereview.appspot.com/324490043/

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

Re: PATCHES - Countdown for September 10th

[Thomas Morley]

2017-09-23 19:04 GMT+02:00 Trevor Daniels :
>
> James wrote Tuesday, September 12, 2017 9:05 AM
>
>
>> On Mon, 11 Sep 2017 23:24:31 +0200
>> Thomas Morley  wrote:
>>
>>> for about a month I'm often surprised about new issues/patches etc.
>>> I _am_ subscribed to the lilypond-auto mailing-list which should
>>> notify me about stuff from the tracker.
>>>
>>> Did I miss a recent change?
>>>
>>> Thanks,
>>>   Harm
>>>
>>
>> If you look here:
>>
>> http://lists.gnu.org/archive/html/lilypond-auto/
>>
>> It seems that the emails stopped 2nd August.
>>
>> I wonder if there is some 'spam' setting that has been triggered on the 
>> lilypond-auto list?
>
> I'm pleased to say the lilypond-auto mailing list is operational again, 
> thanks to excellent help from the SourceForge team.
>
> The problem stemmed from a privacy change around 2 Aug 2017 which required 
> all members of the parent list at SourceForge to resubscribe.  This 
> requirement was communicated to all members of all SourceForge lists, but for 
> some reason this either was not propagated to our lilypond-auto list at 
> gnu.org or we all missed it.  As a result mailings from the SF list to the 
> gnu list stopped.
>
> Getting them working again was tricky.  If you're interested you can see the 
> story here:
> https://sourceforge.net/p/forge/site-support/15567/
>
> You can, of course, subscribe to the SF list directly, cutting out the (now 
> dubious) hop via gnu.org, here:
> https://sourceforge.net/p/testlilyissues/mailman/
>
> Trevor



Hi Trevor,

looks I can confirm it working again.

Many thanks for your work,
  Harm

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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Knut Petersen]

Hi everybody!

The removal of the PDFDontUseFontObjectNum option in ghostscript caused a lot 
of headache during the last days.

Lilypond provides since early 2015 a way to persuade ghostscript to remove 
duplicated fonts from pdfs.
Later the extractpdfmark program was introduced to allow links to other pdfs to 
survive this process.
Also the -dgs-never-embed-fonts was introduced to force ghostscript never to 
embed fonts.
We also have a -dgs-load-fonts option.

All those options influence important details of our postscript code generation.

For ghostscript versions 9.16 and older --bigpdfs might be used with or without 
the -dgs-never-embed-fonts.

For ghostscripts versions 9.17 until the removal of ghostscripts 
PDFDontUseFontObjectNum, --bigpdfs might successfully be used with or without 
-dgs-never-embed-fonts as long as PDFDontUseFontObjectNum is given to 
ghostscript.

For a recent ghostscript without the PDFDontUseFontObjectNum only the combination of lilyponds --bigpdfs with -dgs-never-embed-fonts gives the desired result. The necessity for the extractpdfmark utility has not changed - use it if you link to destinations in other pdf files. Unfortunately our 
lilypond build system missed to use the --bigpdfs option together with the -dgs-never-embed-fonts.


If other people agree that my patch  
solves the problem of exorbitant file sizes, we might live well without ghostscripts 
PDFDontUseFontObjectNum.

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

Re: PATCHES - Countdown for September 10th

[Trevor Daniels]

James wrote Tuesday, September 12, 2017 9:05 AM


> On Mon, 11 Sep 2017 23:24:31 +0200
> Thomas Morley  wrote:
> 
>> for about a month I'm often surprised about new issues/patches etc.
>> I _am_ subscribed to the lilypond-auto mailing-list which should
>> notify me about stuff from the tracker.
>> 
>> Did I miss a recent change?
>> 
>> Thanks,
>>   Harm
>> 
> 
> If you look here:
> 
> http://lists.gnu.org/archive/html/lilypond-auto/
> 
> It seems that the emails stopped 2nd August.
> 
> I wonder if there is some 'spam' setting that has been triggered on the 
> lilypond-auto list?

I'm pleased to say the lilypond-auto mailing list is operational again, thanks 
to excellent help from the SourceForge team.

The problem stemmed from a privacy change around 2 Aug 2017 which required all 
members of the parent list at SourceForge to resubscribe.  This requirement was 
communicated to all members of all SourceForge lists, but for some reason this 
either was not propagated to our lilypond-auto list at gnu.org or we all missed 
it.  As a result mailings from the SF list to the gnu list stopped.

Getting them working again was tricky.  If you're interested you can see the 
story here:
https://sourceforge.net/p/forge/site-support/15567/

You can, of course, subscribe to the SF list directly, cutting out the (now 
dubious) hop via gnu.org, here:
https://sourceforge.net/p/testlilyissues/mailman/

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[trueroad]

`-dgs-never-embed-fonts` doesn't effect for TrueType fonts.
Therefore, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are
used at the same time, TrueType fonts are embedded as full set (ie
non-subset). (if there is no bug in gs.)
On the other hand, some intermeiate PDFs use Japanese TrueType font.
Of course the CJK font is a very large file size.

Combining them means that the size of the final PDF may be smaller but
the size of the intermediate PDFs will be larger.
In my experiment, even if there is a bug in gs's full set font
embedding, the disk size that `make doc` eats has increased.

If I understand correctly, `--bigpdfs` / `-b` has two effects.
One is to embed full set (non-subset) font.
The other is to define and use some encodings for Emmentaler.

In my humble opinion , how about making two options that can specify
each of them individually?
E.g. the former one might be `--dgs-embed-fullset-fonts`.
And ,the latter one might be `--duse-notation-font-encodings`.

Then, `--bigpdfs` / `-b` will be an alias for a combination of
`--dgs-embed-fullset-fonts` and `--duse-notation-font-encodings`.
For `make doc`, use `-dgs-never-embed-fonts
--duse-notation-font-encodings` instead of `-dgs-never-embed-fonts -b`.


https://codereview.appspot.com/325630043/

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

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[knupero]

Reviewers: dak,

Message:
On 2017/09/23 16:02:32, dak wrote:

https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make

File make/lilypond-vars.make (right):



https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make#newcode54

make/lilypond-vars.make:54: -dgs-never-embed-fonts -b
Is there a conceivable application for using -b without

-dgs-never-embed-fonts ?

  If not, shouldn't -b imply -dgs-never-embed-fonts anyway ?  Otherwise

people

are likely to get results they don't expect I think.


It definitely is usefull to be able to use -dgs-never-embed-fonts
without -b.

To force -dgs-never-embed-fonts if -b is used will definitely break
existing scripts. Of course, existing scripts will also be broken by new
versions of ghostscript - but not everyone uses gs versions above 9.16,
and it will take a long time until it is save to assume that everybody
uses at least ghostscript 9.22.

I think it's definitely necessary to add some documentation.

I also have to (and I will) test some old versions of ghostscript.


Description:
Use -b together with -dgs-never-embed-fonts

Signed-off-by: Knut Petersen 

Please review this at https://codereview.appspot.com/325630043/

Affected files (+2, -2 lines):
  M make/lilypond-vars.make
  M make/lysdoc-targets.make


Index: make/lilypond-vars.make
diff --git a/make/lilypond-vars.make b/make/lilypond-vars.make
index  
1fd163caa174dec5cf62a6fac438266049a219b1..0e1b79583e77abfb3a6221562c23eecfbef4b8e2  
100644

--- a/make/lilypond-vars.make
+++ b/make/lilypond-vars.make
@@ -51,7 +51,7 @@ $(LANG_TEXIDOC_FLAGS) \
 ifeq ($(USE_EXTRACTPDFMARK),yes)
 LILYPOND_BOOK_LILYPOND_FLAGS+= \
 -dfont-export-dir=$(top-build-dir)/out-fonts \
--dgs-never-embed-fonts
+-dgs-never-embed-fonts -b
 endif

 ifdef QUIET_BUILD
Index: make/lysdoc-targets.make
diff --git a/make/lysdoc-targets.make b/make/lysdoc-targets.make
index  
547614cbd5164842da94832aa7123a841e51fe02..43f1babf04a21851a38a0c1ee5192a6cfd46e862  
100644

--- a/make/lysdoc-targets.make
+++ b/make/lysdoc-targets.make
@@ -17,7 +17,7 @@ local-test:
(cd $(top-src-dir) && git diff ) ; \
fi > $(outdir)/tree.gittxt
 ifeq ($(USE_EXTRACTPDFMARK),yes)
-	$(MAKE) LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=ps  
$(LILYPOND_JOBS) -dseparate-log-files -dinclude-eps-fonts -dgs-load-fonts  
--header=texidoc -I $(top-src-dir)/Documentation/included/ -ddump-profile  
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1  
-dfont-export-dir=$(top-build-dir)/out-fonts -dgs-never-embed-fonts"  
LILYPOND_BOOK_WARN= $(outdir)/collated-files.html  
LYS_OUTPUT_DIR=$(top-build-dir)/out/lybook-testdb
+	$(MAKE) LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=ps  
$(LILYPOND_JOBS) -dseparate-log-files -dinclude-eps-fonts -dgs-load-fonts  
--header=texidoc -I $(top-src-dir)/Documentation/included/ -ddump-profile  
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1  
-dfont-export-dir=$(top-build-dir)/out-fonts -dgs-never-embed-fonts -b"  
LILYPOND_BOOK_WARN= $(outdir)/collated-files.html  
LYS_OUTPUT_DIR=$(top-build-dir)/out/lybook-testdb

 else
 	$(MAKE) LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=ps  
$(LILYPOND_JOBS) -dseparate-log-files -dinclude-eps-fonts  
-dgs-load-lily-fonts --header=texidoc -I  
$(top-src-dir)/Documentation/included/ -ddump-profile  
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1"  
LILYPOND_BOOK_WARN= $(outdir)/collated-files.html  
LYS_OUTPUT_DIR=$(top-build-dir)/out/lybook-testdb

 endif



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

Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

[dak]

https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make
File make/lilypond-vars.make (right):

https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make#newcode54
make/lilypond-vars.make:54: -dgs-never-embed-fonts -b
Is there a conceivable application for using -b without
-dgs-never-embed-fonts ?  If not, shouldn't -b imply
-dgs-never-embed-fonts anyway ?  Otherwise people are likely to get
results they don't expect I think.

https://codereview.appspot.com/325630043/

___
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

[suzuki toshiya]

Dear Hosoda-san,

Thank you for posting very detailed package to reproduce the issue,
it was far detailed than I expected. Please let me spend some time
to check it, due to I'm absent from my office in next week...

Regards,
mpsuzuki

Masamichi Hosoda wrote:
>> 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: Fwd: You Made Our List: The 50 Best Music Tools Online

[Karlin High]

On Sat, Sep 23, 2017 at 3:01 AM, Francisco Vila  wrote:
> Also, is lilypond really an online tool?

I noticed that, too. Then I remembered lilybin.com.
--
Karlin High
Missouri, USA

___
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]

> Note that I didn't attempt this on 9.21, just the 9.22 release
> candidate. While the fonts are properly dropped from the individual
> PDF files, none of the text was visible in the final PDF file, when
> rebuilding with Emmentaler supplied as an external font in fontmap.GS.
> 
> Its interesting that the OTF worked for you because I would expect it
> to; OTF fonts with CFF outlines are handled simply be extracting the
> CFF, which is usable directly in PostSceript. TrueType fonts are not
> directly supported by PostScript and that's where the heuristics come
> back again, we have to guess at some aspects of the encodings.

In my experiment, I used gs-9.22rc1 but I didn't use fontmap.GS.

Instead, I created a PostScript file
that contains only font resource in the same format as EPSs.
That is, for the  Emmentaler-20 font,
I created a file `fonts/Emmentaler-20.font.ps` with the following contents.

```
%%BeginFont: Emmentaler-20
%%BeginResource: font Emmentaler-20
%!PS-Adobe-3.0 Resource-FontSet
%%DocumentNeededResources: ProcSet (FontSetInit)
%%Title: (FontSet/Emmentaler-20)
%%Version: 0
%%EndComments
%%IncludeResource: ProcSet (FontSetInit)
%%BeginResource: FontSet (Emmentaler-20)
/FontSetInit /ProcSet findresource begin
%%BeginData: 67355 Binary Bytes
[...snip...]
%%EndData
%%EndResource
%%EndResource
%%EndFont
```

Then, I invoked Ghostscipt with the following command.

$ gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite \
 -sOutputFile=include-bigpdfs-noembed-gse.pdf \
 -c ".setpdfwrite" \
 -f fonts/*.font.ps include-bigpdfs-noembed.pdf

`fonts/Emmentaler-20.font.ps` and other font files
`fonts/TeXGyreSchola-Regular.font.ps` etc. are in my sample tarball.

In this method, for TrueType fonts,
I think that the encoding is confusing and broken as you mentioned.

___
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 02:35 23/09/2017 +0900, Masamichi Hosoda wrote:



> 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.


That was what I had tried. IMO its the fact that its an OpenType font, ie a 
TrueType font with CFF outlines, which is the problem rather than it being 
TrueType.


However, I haven't attempted to diagnose why that didn't work either.

Note that I didn't attempt this on 9.21, just the 9.22 release candidate. 
While the fonts are properly dropped from the individual PDF files, none of 
the text was visible in the final PDF file, when rebuilding with Emmentaler 
supplied as an external font in fontmap.GS.


Its interesting that the OTF worked for you because I would expect it to; 
OTF fonts with CFF outlines are handled simply be extracting the CFF, which 
is usable directly in PostSceript. TrueType fonts are not directly 
supported by PostScript and that's where the heuristics come back again, we 
have to guess at some aspects of the encodings.




Ken


___
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]

Francisco Vila  writes:

> On 22/09/17 16:47, David Kastrup wrote:
>>
>> 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
>
> Also, is lilypond really an online tool?

Well, for native speakers of Germanic languages there may be more of an
intuitive difference between "Music Tools Online" and "Online Music
Tools".

I think this is just talking about Music Tools that have an online
presence (like being downloadable).

-- 
David Kastrup

___
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

[Francisco Vila]

On 22/09/17 16:47, David Kastrup wrote:
>
> 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
>

Also, is lilypond really an online tool?

-- 
Francisco Vila. Badajoz (Spain)
paconet.org , csmbadajoz.com


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