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

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

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

David Kastrup

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knupero@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 <[hidden email]>

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

trueroad
In reply to this post by David Kastrup
`-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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

knupero
In reply to this post by David Kastrup

> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

trueroad
In reply to this post by David Kastrup
On 2017/09/24 00:25:17, knupero wrote:
> > 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.

I wrote "to define and *use* the some encodings".
If I understand correctly, "glyphshow" doesn't use any encodings but
"show" uses the encoding.
What I wrote as "use" means using "show" instead of "glyphshow".

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

Again, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are used
at the same time, the intermediate PDFs become larger.
The disk size that `make doc` eats becomes increased.

If spliting -b, `-dgs-never-embed-fonts -duse-notation-font-encodings`
doesn't embed full set TrueType fonts.
It embeds subset for TrueType fonts, as with only using
`-dgs-never-embed-fonts`.
The intermediate PDFs don't become larger.
The disk size that `make doc` eats doesn't become increased.
Nevertheless, the encodings for notation font is defined and "show" is
used.
In my humble opinion, this is better than `-dgs-never-embed-fonts -b`.

Of course, if we do not have to worry about the increase in disk size
required, splitting -b is senseless as you wrote.

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

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

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

David Kastrup
In reply to this post by David Kastrup
On 2017/09/24 10:05:43, trueroad wrote:
> On 2017/09/24 00:25:17, knupero wrote:
> > > 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.

> I wrote "to define and *use* the some encodings".
> If I understand correctly, "glyphshow" doesn't use any encodings but
"show" uses
> the encoding.
> What I wrote as "use" means using "show" instead of "glyphshow".

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

> Again, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are
used at the
> same time, the intermediate PDFs become larger.
> The disk size that `make doc` eats becomes increased.

> If spliting -b, `-dgs-never-embed-fonts -duse-notation-font-encodings`
doesn't
> embed full set TrueType fonts.
> It embeds subset for TrueType fonts, as with only using
> `-dgs-never-embed-fonts`.
> The intermediate PDFs don't become larger.
> The disk size that `make doc` eats doesn't become increased.
> Nevertheless, the encodings for notation font is defined and "show" is
used.
> In my humble opinion, this is better than `-dgs-never-embed-fonts -b`.

> Of course, if we do not have to worry about the increase in disk size
required,
> splitting -b is senseless as you wrote.

In my opinion, -b/--bigpdf should be simple to use for
lilypond-book-like applications.  lilypond-book should likely call
lilypond using options leading to good results by default.  For
generating our own documentation, I find 3-4GB of disk space excessive:
using special additional options might be suitable if that helps.  If
the additional options work at least as well under all conceivable
circumstances, they should likely be the default.

-dxxx are options appealing more to specialists (well, there are things
like -dpreview not particularly specialist, but when in doubt, people
are more likely to see/consider "normal" options).

I'm not into the whole font mess enough to make a really qualified
suggestion here.

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

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

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

trueroad
In reply to this post by David Kastrup
On 2017/09/24 11:03:26, dak wrote:
> In my opinion, -b/--bigpdf should be simple to use for
lilypond-book-like
> applications.  lilypond-book should likely call lilypond using options
leading
> to good results by default.  For generating our own documentation, I
find 3-4GB
> of disk space excessive: using special additional options might be
suitable if
> that helps.  If the additional options work at least as well under all
> conceivable circumstances, they should likely be the default.

> -dxxx are options appealing more to specialists (well, there are
things like
> -dpreview not particularly specialist, but when in doubt, people are
more likely
> to see/consider "normal" options).

> I'm not into the whole font mess enough to make a really qualified
suggestion
> here.

To make the options simple, what about doing as follows?



* --bigpdfs / -b

Keep its behavior

i.e.
- Define and use some encodings for Emmentaler. (Also using "show"
instead of "glyphshow")
- For PDF output, embed full set (non-subset) font (if there is no bugs
in Ghostscript)

This option is for full set (non-subset) embedded font intermediate
PDFs, and later uses MuPDF etc. to remove duplicate the fonts.

This method is simple and easy to understand.
However, the size of the intermediate PDF increases.
Also, the current Ghostscript does not work properly because there seems
to be a bug in which full set of fonts can not be embedded.



* -dgs-neverembed-fonts

Add behavior

Current behavior
- For PDF output, It does not embed fonts except TrueType fonts.

Added behavior
- Define and use some encodings for Emmentaler. (Also using "show"
instead of "glyphshow")
- For PDF output, It does not embed fonts except TrueType fonts.

This option is for non-embedded font intermediate PDFs, and later uses
Ghostscript to embed missing fonts.

This method needs to pass the missing fonts to Ghostscript.
In other words, it is for specialists.
However, if it is used properly, it works even with the current
Ghostscript.


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

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

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

Carl Sorensen
In reply to this post by David Kastrup
On 2017/09/24 14:32:02, trueroad wrote:

> * -dgs-neverembed-fonts

> Add behavior

> Current behavior
> - For PDF output, It does not embed fonts except TrueType fonts.

> Added behavior
> - Define and use some encodings for Emmentaler. (Also using "show"
instead of
> "glyphshow")
> - For PDF output, It does not embed fonts except TrueType fonts.

> This option is for non-embedded font intermediate PDFs, and later uses
> Ghostscript to embed missing fonts.

> This method needs to pass the missing fonts to Ghostscript.
> In other words, it is for specialists.
> However, if it is used properly, it works even with the current
Ghostscript.

So if I understand this correctly, properly using -dgs-neverembed-fonts
as part of our manual build process will give us *both* smaller
intermediate files and a small final file?  That sounds perfect to me!

Carl




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

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

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

knupero
In reply to this post by David Kastrup
A bit more far-reaching.

As newer versions of gs
   - don't need the helpemmentaler functions and
   - don't need the real inclusion of all font data and
   - don't need some other details and
   - don't work properly with our old code
we might well decide to kill --bigpdfs.

Instead of --bigpdfs this patch introduces --use-encodings

--use-encodings switches emmentaler glyph generation from "glyphshow" to
"show"+encodings and might be combined width -dgs-never-embed-fonts.

With --use-encodings there is an increase in file size, but it is not
dramatic. Nevertheless it should not be the default.

This patch gives a total size of 96MB for all of our documentation pdfs
on my system if used with ghostscript git master or at least ghostscript
9.20. Also extractpdfmark must be used.

If you use ghostscript versions below 9.20 or if extractpdfmark is not
present on your system, the total size of the documentation is about 306
MB.

du -sh build/ gives 2.6GB after a full build with this patch, 2.5GB
without it. Disk usage during the build probably is higher.

The last stage of building the pdfs does cost a significant amount of
processing time: generating the 306MB set of pdfs takes about 940
seconds on my system, generating the 96MB set of pdf takes an additional
110 seconds.

Documentation needs to be finished.

Please test on your systems.



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

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

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

knupero
In reply to this post by David Kastrup
https://codereview.appspot.com/325630043/

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

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

David Kastrup
In reply to this post by David Kastrup
On 2017/09/25 12:13:34, knupero wrote:
> kill --bigpdfs, introduce --use-encodings, remove code not needed by
ghostscript
> 9.20+

On my system (Ubuntu Aarkvard) I have Ghostscript 9.21 which is fine.
Usually we try to support the last LTS versions of Ubuntu, possibly
RedHat (and Debian unstable ?).  Since we need to get our house in order
for the stable 2.20 release, I'd very much like to have a PostScript
setup we are comfortable with in the 2.20 release, and that means that
this patch (or some variation of it) should go in.

I don't really have a clue here: can someone chime in with the current
Ghostscript versions in possibly concerned distributions?  Naturally
including our own Gub-based ones?

Or is 9.20+ just a conservative estimate and older versions will (or
might) likely work as well?

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

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

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

David Kastrup
In reply to this post by David Kastrup
On 2017/09/25 12:54:24, knupero wrote:
> A bit more far-reaching.

> As newer versions of gs
>    - don't need the helpemmentaler functions and
>    - don't need the real inclusion of all font data and
>    - don't need some other details and
>    - don't work properly with our old code
> we might well decide to kill --bigpdfs.

> Instead of --bigpdfs this patch introduces --use-encodings

> --use-encodings switches emmentaler glyph generation from "glyphshow"
to
> "show"+encodings and might be combined width -dgs-never-embed-fonts.

That sounds good.  It also sounds like -dgs-never-embed-fonts should
imply --use-encodings, right?

> With --use-encodings there is an increase in file size, but it is not
dramatic.
> Nevertheless it should not be the default.

I think it really depends on what "is not dramatic" means.  How is the
impact on really large scores?  If the percentages are comparatively
small, I think we are better off making the option most amicable to
further processing of PDF files the default.

Users or scripts that are sure that they do not want any further
processing can then use --final-pdf (or whatever) if they know that the
size/speed wins have no negative side effects for them.  But the default
setting should be the one least likely to cause followup problems.

> This patch gives a total size of 96MB for all of our documentation
pdfs on my
> system if used with ghostscript git master or at least ghostscript
9.20. Also
> extractpdfmark must be used.

> If you use ghostscript versions below 9.20 or if extractpdfmark is not
present
> on your system, the total size of the documentation is about 306 MB.

That's sort-of unpleasant but we can likely declare this temporary
constellation "somebody else's problem" as long as our lilydev VM and
the gub distributions are recent enough not to be affected.

> du -sh build/ gives 2.6GB after a full build with this patch, 2.5GB
without it.
> Disk usage during the build probably is higher.

Even if we are using -dgs-never-embed-fonts for the included files?  I
mean, the numbers are smaller than what I remember but still rather
large.

> The last stage of building the pdfs does cost a significant amount of
processing
> time: generating the 306MB set of pdfs takes about 940 seconds on my
system,
> generating the 96MB set of pdf takes an additional 110 seconds.

I assume that the additional time is in Ghostscript/extractpdfmark so
that there is little in the way of improving LilyPond itself?


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

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

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

trueroad
In reply to this post by David Kastrup
On 2017/09/25 13:21:44, dak wrote:
> I don't really have a clue here: can someone chime in with the current
> Ghostscript versions in possibly concerned distributions?  Naturally
including
> our own Gub-based ones?

GUB has Ghostscript 9.21 except freebsd-x86.
(Ghostscript 9.2x for freebsd-x86 raises seg fault. So Ghostscript 9.15
is used for freebsd-x86.)

GUB also has extractpdfmark.

> Or is 9.20+ just a conservative estimate and older versions will (or
might)
> likely work as well?

Ghostscript 9.20+ is needed.
Ghostscript 9.19 doesn't work fine.
9.19 can not handle some named destinations like Unicode strings that
generated by Texinfo.
https://bugs.ghostscript.com/show_bug.cgi?id=696974




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

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

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

knupero
In reply to this post by David Kastrup

> > --use-encodings switches emmentaler glyph generation from
"glyphshow" to
> > "show"+encodings and might be combined width -dgs-never-embed-fonts.

> That sounds good.  It also sounds like -dgs-never-embed-fonts should
imply
> --use-encodings, right?

No. There are legitimate uses for both standalone -dgs-never-embed-fonts
and --use-encodings.

> I think it really depends on what "is not dramatic" means.  How is the
impact on
> really large scores?  If the percentages are comparatively small, I
think we are
> better off making the option most amicable to further processing of
PDF files
> the default.

All scores tested here (only a few) increased about 10% to 20% in size.
But the code paths are old and proven, we should keep both.

> Users or scripts that are sure that they do not want any further
processing can
> then use --final-pdf (or whatever) if they know that the size/speed
wins have no
> negative side effects for them. But the default setting should be the
one least
> likely to cause followup problems.

I believe that the ordinary user of lilypond does one score at a time
without further processing. And Fred Foobar probably would complain if
his old scores grow bigger with 2.20.

> > If you use ghostscript versions below 9.20 or if extractpdfmark is
not present
> > on your system, the total size of the documentation is about 306 MB.

At least they are not broken ;-)

> That's sort-of unpleasant but we can likely declare this temporary
constellation
> "somebody else's problem" as long as our lilydev VM and the gub
distributions
> are recent enough not to be affected.

Nobody who builds lilypond documentation should use a ghostscript old
than 9.20. As pointed out by Masamichi, GoToR links are not processed
correctly by all older versions of ghostscript. Of course, as not all
pdf readers process them correctly, a lot of people would not see that
problem. Some examples: okular does not process them at all, evince
handles them correctly (but fails on link types not used by our
documentation), and mupdf handles them incorrectly (but correctly
implements other links that are broken by evince bugs).

If I would know that 9.20+ is available on every system supported by
lilypond I would advocate to make that version a build requirement.

> Even if we are using -dgs-never-embed-fonts for the included files?  I
mean, the
> numbers are smaller than what I remember but still rather large.

Yes. Even with -dgs-never-embed-fonts.

> I assume that the additional time is in Ghostscript/extractpdfmark so
that there
> is little in the way of improving LilyPond itself?

I think you are right with that assumption.

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

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

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

knupero
In reply to this post by David Kastrup

> I don't really have a clue here: can someone chime in with the current
> Ghostscript versions in possibly concerned distributions?  Naturally
including
> our own Gub-based ones?

OpenSuSE Tumbleweed: 9.21
OpenSuSE Leap: 9.15, but also offers 9.21



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

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

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

David Kastrup
In reply to this post by David Kastrup
Why are we still navigating the bleeding edge?  LilyPond is more than 20
years old.

On 2017/09/25 16:38:16, knupero wrote:
> > > --use-encodings switches emmentaler glyph generation from
"glyphshow" to
> > > "show"+encodings and might be combined width
-dgs-never-embed-fonts.
> >
> > That sounds good.  It also sounds like -dgs-never-embed-fonts should
imply
> > --use-encodings, right?

> No. There are legitimate uses for both standalone
-dgs-never-embed-fonts and
> --use-encodings.

I see.  Still using -dgs-never-embed-fonts _without_ --use-encodings
seems like the most unusual combination, so I'd prefer if one had to
explicitly switch encodings _off_ rather than _on_.

> > I think it really depends on what "is not dramatic" means.  How is
> > the impact on really large scores?  If the percentages are
> > comparatively small, I think we are better off making the option
> > most amicable to further processing of PDF files the default.

> All scores tested here (only a few) increased about 10% to 20% in
> size.

As long as they were large, that would seem representative.  I was
hoping for less.

> But the code paths are old and proven, we should keep both.

Well, I wasn't suggesting otherwise, at least in the short term.  But
it seemed like putting the glyphshow way behind an explicit option
would have had benefits for making the default PDF files more
versatile.

This is all more murky than I like.

> > Users or scripts that are sure that they do not want any further
> > processing can then use --final-pdf (or whatever) if they know
> > that the size/speed wins have no negative side effects for
> > them. But the default setting should be the one least likely to
> > cause followup problems.

> I believe that the ordinary user of lilypond does one score at a
> time without further processing. And Fred Foobar probably would
> complain if his old scores grow bigger with 2.20.

Depends on how much.  10-20% would make a difference, I'm just not
sure enough for a complaint.  And we would retain the option
--final-pdf (or whatever) for making them with the old size.

> > > If you use ghostscript versions below 9.20 or if extractpdfmark
> > > is not present on your system, the total size of the
> > > documentation is about 306 MB.

> At least they are not broken ;-)

That's the main excuse.  And it wasn't better before we came up with
the --bigpdf scheme.

> > That's sort-of unpleasant but we can likely declare this temporary
> > constellation "somebody else's problem" as long as our lilydev VM
> > and the gub distributions are recent enough not to be affected.

> Nobody who builds lilypond documentation should use a ghostscript
> old than 9.20.  As pointed out by Masamichi, GoToR links are not
> processed correctly by all older versions of ghostscript. Of course,
> as not all pdf readers process them correctly, a lot of people would
> not see that problem. Some examples: okular does not process them at
> all, evince handles them correctly (but fails on link types not used
> by our documentation), and mupdf handles them incorrectly (but
> correctly implements other links that are broken by evince bugs).

> If I would know that 9.20+ is available on every system supported by
> lilypond I would advocate to make that version a build requirement.

I think you could still override such a requirement with

GS=/usr/bin/gs ./configure ...

or similar so I am somewhat sympathetic to that.

Sigh.

Why can't anything be easy?


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

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

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

knupero
In reply to this post by David Kastrup
On 2017/09/25 17:33:47, dak wrote:
> Why are we still navigating the bleeding edge?  LilyPond is more than
20 years
> old.

I remember a company that failed to get flash right.

Ghostscript still fails on GoToR without the help of extractpdfmarks ;-)



> On 2017/09/25 16:38:16, knupero wrote:
> > > > --use-encodings switches emmentaler glyph generation from
"glyphshow" to
> > > > "show"+encodings and might be combined width
-dgs-never-embed-fonts.
> > >
> > > That sounds good.  It also sounds like -dgs-never-embed-fonts
should imply
> > > --use-encodings, right?
> >
> > No. There are legitimate uses for both standalone
-dgs-never-embed-fonts and
> > --use-encodings.

> I see.  Still using -dgs-never-embed-fonts _without_ --use-encodings
seems like
> the most unusual combination, so I'd prefer if one had to explicitly
switch
> encodings _off_ rather than _on_.

So you are absolutely sure that enabling "show" and the use of encodings
does not break anything?

What about other notation fonts?

About three weeks ago Malte Meyn complained on lilypond-user that
"lilypond -b" failed with the Haydn font.

Remember: We used the hardcoded name "Emmentaler" at various places for
--bigpdfs, and --use-encodings still needs and uses that portion of the
old code.

I have not checked that in detail, but I believe that we need to adapt
ps/encodingdefs.ps and scm/output-ps to support other notation fonts
with --use-encodings.

Ceterum censeo: We really should stay with glyphshow as our default for
lilypond 2.20 (two-two-zero).


> This is all more murky than I like.

I totally agree.


> Sigh.

> Why can't anything be easy?

If it would be too easy someone would complain that it is boring ;-))

There is enough to be done for the lilypond 2.21 (two-two-one) low-level
postscript interface:
-  Support other notation fonts with --use-encodings
-  Change the code path that uses print_glyphs to also allow the use of
encodings and show.
-  We should change our eps inclusion code to allow to reuse an image
once it is loaded.
-  We should include a well defined way to set a background color, to
use an background image, and to allow a transparent overlay.
-  We even might discuss if it is wise to keep a separate svg backend as
it is easy to translate postscript to svg.
-  Someone probably will propose to add ghostscript as a git submodule
to the lilypond tree and to add some patches.

Don't complain that this isn't easy, be happy that there are at least
two persons working on this part of the code.


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

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

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

David Kastrup
In reply to this post by David Kastrup
On 2017/09/25 22:17:41, knupero wrote:
> On 2017/09/25 17:33:47, dak wrote:

> > I see.  Still using -dgs-never-embed-fonts _without_
> > --use-encodings seems like the most unusual combination, so I'd
> > prefer if one had to explicitly switch encodings _off_ rather than
> > _on_.

> So you are absolutely sure that enabling "show" and the use of
> encodings does not break anything?

> What about other notation fonts?

> About three weeks ago Malte Meyn complained on lilypond-user that
> "lilypond -b" failed with the Haydn font.

> Remember: We used the hardcoded name "Emmentaler" at various places
> for --bigpdfs, and --use-encodings still needs and uses that portion
> of the old code.

Before remembering something, I need to know it in the first place.
Sounds like something we should get rid off in the long run.

> I have not checked that in detail, but I believe that we need to
> adapt ps/encodingdefs.ps and scm/output-ps to support other notation
> fonts with --use-encodings.

> Ceterum censeo: We really should stay with glyphshow as our default
> for lilypond 2.20 (two-two-zero).

Well, hard to argue with that.

Nevertheless, for 2.21+ I would want to move to a different default,
so it makes sense to bikeshed the naming of the option(s) such that we
only need to flip the default at some point of time.  Scripts should
already be able to explicitly decide which side of the default they
want to end up with (and will then do so regardless of whether the
default has been flipped).

Regarding the naming of the option, I'd prefer to have something
oriented around the actual use characteristics rather than the
internal details.

Does that sound like something you can agree with?

> - We even might discuss if it is wise to keep a separate svg backend
> as it is easy to translate postscript to svg.

I would not want to touch this before we have Cairo in place.  The
PostScript path is inherently slower than any more direct option, so
if retiring SVG as an explicit backend would be on the slate, a
Cairo-based path would seem to make a lot more sense.

> - Someone probably will propose to add ghostscript as a git
> submodule to the lilypond tree and to add some patches.

I doubt we could reasonably afford the ongoing cost of even a small
fork.  So as long as we can coordinate efforts with upstream, that
seems vastly preferable.


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

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

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

knupero
In reply to this post by David Kastrup

> > Remember: We used the hardcoded name "Emmentaler" at various places
> > for --bigpdfs, and --use-encodings still needs and uses that portion
> > of the old code.

> Before remembering something, I need to know it in the first place.
> Sounds like something we should get rid off in the long run.

Yes. I never used an alternative music font, and I don't have the
details
how the Authors implement them. This morning I wrote to Abraham Lee.

> Nevertheless, for 2.21+ I would want to move to a different default,
> so it makes sense to bikeshed the naming of the option(s) such that we
> only need to flip the default at some point of time.  Scripts should
> already be able to explicitly decide which side of the default they
> want to end up with (and will then do so regardless of whether the
> default has been flipped).

> Regarding the naming of the option, I'd prefer to have something
> oriented around the actual use characteristics rather than the
> internal details.

> Does that sound like something you can agree with?

Yes. That sounds reasonable.

If you know a better name for the option I'd happy to start sed.

> > - Someone probably will propose to add ghostscript as a git
> > submodule to the lilypond tree and to add some patches.

> I doubt we could reasonably afford the ongoing cost of even a small
> fork.  So as long as we can coordinate efforts with upstream, that
> seems vastly preferable.

We'll talk about that in some months ;-)

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

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

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

David Kastrup
In reply to this post by David Kastrup
On 2017/09/26 20:26:36, knupero wrote:

> > Regarding the naming of the option, I'd prefer to have something
> > oriented around the actual use characteristics rather than the
> > internal details.
> >
> > Does that sound like something you can agree with?

> Yes. That sounds reasonable.

> If you know a better name for the option I'd happy to start sed.

--final-output ?  --flatten-fonts ?  Not sure about the inversions of
those, however.

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

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