Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)
https://codereview.appspot.com/343970043/diff/60001/mf/GNUmakefile File mf/GNUmakefile (right): https://codereview.appspot.com/343970043/diff/60001/mf/GNUmakefile#newcode165 mf/GNUmakefile:165: cd $(outdir) && mv $(notdir $<) $(notdir $@) Is it necessary to change the file name? I think that the extension `.otf' is more suitable than the extension `.cid' since `emmentaler-*-cid.otf' is in Open Type Font format. If I understand correctly, a file with extension `.cid' means old CID format instead of OTF format. The OTF format can contain a CID keyed fonts as well as non-CID keyed fonts. https://codereview.appspot.com/343970043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)
What are the scripts these 'test' dirs? Those are actual tests for the added functionality, runnable with `pytest`. Was this a mistake? No, I believe that these tests are individually useful, even though not yet integrated into the Lilypond testing system. If you prefer, though, I can leave them out. https://codereview.appspot.com/34443/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)
On 2018/06/01 11:50:31, a.myltsev wrote: musicxml2ly: hidden timesigs and tempo marks with text. What are the scripts these 'test' dirs? Was this a mistake? If so can you re-submit the patch please? thanks James https://codereview.appspot.com/34443/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gs -dNOSAFER / windows
Knut Petersen writes: > Am 30.05.2018 um 13:34 schrieb Knut Petersen: >> Am 30.05.2018 um 11:49 schrieb David Kastrup: >>> -dSAFER, that is broken on windows. >>> >>> >>> So the question is: has that apparent group read permission problem (?) >>> been fixed in the last 13 years? >>> >>> Unless somebody has a clue, I lean towards just trying this out and >>> waiting for problem reports. At least we should know more or less what >>> to expect now. >>> >> We could add $lilypond-datadir/fonts/otf/ and $lilypond-datadir/ps to the >> permitted gs resources on the gs command line. Or we explicitly allow all >> the external fonts used in the document and always use -dSAFER. > > As there is a limit of 2048 bytes for command line arguments in ghostscript > and > I managed to hit that limit with experimental code I propose the > following solution: > > 1. Never use -dSAFER and -dNOSAFER on the ghostscript command line. > > 2. No special handling of the gs / windows environment. > > 3. Always start a postscript file generated by lilypond with code like: > >%!PS-Adobe-3.0 >%%Creator: LilyPond 2.21.0 >%%Pages: 1 >%%PageOrder: Ascend >%%Orientation: Portrait >%%DocumentMedia: a4 595.28 841.89 80 () () >%%DocumentSuppliedResources: font Emmentaler-20 >%%DocumentSuppliedResources: font TeXGyreSchola-Regular >%%EndComments >%%BeginProlog > ><< /PermitFileReading [ > > (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/music-drawing-routines.ps) >(/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/lilyponddefs.ps) > > (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/fonts/otf/emmentaler-11.otf) >[... a lot of files omitted ...] >(/usr/share/fonts/texlive-tex-gyre/texgyreschola-regular.otf) >] >> setuserparams .locksafe > > That means we always give a list of all files the document needs > (fonts, our helper files) to ghostscript > and then activate ghostscripts safe mode from within the postscript file. > > As this could break usage of eps files that try to access external > files and unsafe postscript code entered > via \markup \postscript I propose to add a command line option > '--unsafe-ps' to allow a brave Fred Foobar > to use the full power of postscript. > > Comments? Objections? Yes to not putting stuff like the file reading permissions on the command line. I don't like using .locksafe as opposed to -DSAFER and -DDELAYSAFER (?) command line options because Ghostscript has a history of fscking around with any commands not in the PostScript standard. For example, the current Ghostscript man page states: When running with -dNOSAFER it is possible to perform a "save" followed by ".setsafe", execute a file or procedure in SAFER mode, and then use "restore" to return to NOSAFER mode. In order to prevent the save object from being restored by the foreign file or procedure, the ".runandhide" operator should be used to hide the save object from the restricted procedure. and in spite of this documentation, Ghostscript has just removed the .runandhide operator without notice, keeping this documentation. I've been (co-)authoring Ghostscript support for AUCTeX's preview-latex mode and every year or two preview-latex stops working because Ghostscript has yet again fscked around with internals previously documented as doing what they should. Actually, even the man page (even while apparently not viewed as authoritive by Ghostscript developers) states: While SAFER mode is not the default, it is the default for many wrapper scripts such as ps2pdf and may be the default in a subsequent release of Ghostscript. Thus when running programs that need to open files or set restricted parameters you should pass the -dNOSAFER command line option or its synonym -dDELAYSAFER. I don't see us getting around .locksafe at the current point of time, though, so at least in that regard we might need to bite the bullet, but add -DDELAYSAFER on the command line. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gs -dNOSAFER / windows
Am 30.05.2018 um 13:34 schrieb Knut Petersen: Am 30.05.2018 um 11:49 schrieb David Kastrup: -dSAFER, that is broken on windows. So the question is: has that apparent group read permission problem (?) been fixed in the last 13 years? Unless somebody has a clue, I lean towards just trying this out and waiting for problem reports. At least we should know more or less what to expect now. We could add $lilypond-datadir/fonts/otf/ and $lilypond-datadir/ps to the permitted gs resources on the gs command line. Or we explicitly allow all the external fonts used in the document and always use -dSAFER. As there is a limit of 2048 bytes for command line arguments in ghostscript and I managed to hit that limit with experimental code I propose the following solution: 1. Never use -dSAFER and -dNOSAFER on the ghostscript command line. 2. No special handling of the gs / windows environment. 3. Always start a postscript file generated by lilypond with code like: %!PS-Adobe-3.0 %%Creator: LilyPond 2.21.0 %%Pages: 1 %%PageOrder: Ascend %%Orientation: Portrait %%DocumentMedia: a4 595.28 841.89 80 () () %%DocumentSuppliedResources: font Emmentaler-20 %%DocumentSuppliedResources: font TeXGyreSchola-Regular %%EndComments %%BeginProlog << /PermitFileReading [ (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/music-drawing-routines.ps) (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/lilyponddefs.ps) (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/fonts/otf/emmentaler-11.otf) [... a lot of files omitted ...] (/usr/share/fonts/texlive-tex-gyre/texgyreschola-regular.otf) ] >> setuserparams .locksafe That means we always give a list of all files the document needs (fonts, our helper files) to ghostscript and then activate ghostscripts safe mode from within the postscript file. As this could break usage of eps files that try to access external files and unsafe postscript code entered via \markup \postscript I propose to add a command line option '--unsafe-ps' to allow a brave Fred Foobar to use the full power of postscript. Comments? Objections? Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for June 1st
Hello, Here is the current patch countdown list. The next countdown will be on June 4th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5331 Let general-column deal reliable with empty args - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5331 http://codereview.appspot.com/346030043 Countdown: 5332 \denies C should cancel \defaultchild C - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5332 http://codereview.appspot.com/346050043 5323 sort input files - Bernhard Wiedemann https://sourceforge.net/p/testlilyissues/issues/5323 http://codereview.appspot.com/347770043 Review: No patches in Review at this time. New: 5333 musicxml2ly: hidden timesigs and tempo marks with text. - avmyltsev https://sourceforge.net/p/testlilyissues/issues/5333 http://codereview.appspot.com/34443 Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Write access to issue tracker
Done. -- Phil Holmes - Original Message - From: "Alexander Myltsev" To: Sent: Thursday, May 31, 2018 11:36 PM Subject: Write access to issue tracker Hi, could someone please give me write access to the Lilypond issue tracker? My Sourceforge account name is avmyltsev. I'd like to submit some minor patches to musicxml2ly, currently available on Github: https://github.com/avm/lilypond/commits/musicxml2ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
