Re: The hel-arabic.ly file story...
Amir, I'm a little late to this thread but thought I'd chime in since Karlin High mentioned my name. I'm around (Adam Good) and though I worked on the turkish-makam.ly file and Turkish makam is most my specialty, I'd be happy to look at any ly file you may be working on currently and give my thoughts or thumbs up. Best, Adam Good On Wed, Dec 28, 2022 at 5:52 PM Karlin High wrote: > On 12/28/2022 4:09 PM, Werner LEMBERG wrote: > > asking you or others > Who else do we have? > > Hans Åberg? > > Adam Good? > > Graham Breed? > > I lose track of their alignments with Turkish vs Persian vs Arabic music. > -- > Karlin High > Missouri, USA > >
Re: LSR “Figured bass with alternate baroque notation”
Le 09/01/2023 à 00:58, Werner LEMBERG a écrit : You may want to look at whether https://lsr.di.unimi.it/LSR/Item?id=1076 can/should be updated now that 2.24 supports some of the glyphs shown. Hmm. The first five glyphs in the snippet are now part of the Emmentaler font, but the next eight are not. Actually, I have never seen such symbols, and the SmuFL standard doesn't have this either. Where are they taken from? Does someone have evidence for the existence of those glyphs? Maybe Valentin (in CC) wants to comment? OpenPGP_signature Description: OpenPGP digital signature
Re: LSR “Figured bass with alternate baroque notation”
> You may want to look at whether > https://lsr.di.unimi.it/LSR/Item?id=1076 can/should be updated now > that 2.24 supports some of the glyphs shown. Hmm. The first five glyphs in the snippet are now part of the Emmentaler font, but the next eight are not. Actually, I have never seen such symbols, and the SmuFL standard doesn't have this either. Where are they taken from? Does someone have evidence for the existence of those glyphs? Werner
LSR “Figured bass with alternate baroque notation”
Hi Werner, You may want to look at whether https://lsr.di.unimi.it/LSR/Item?id=1076 can/should be updated now that 2.24 supports some of the glyphs shown. OpenPGP_signature Description: OpenPGP digital signature
Re: Missing items to make Cairo ready
On Sun, 2023-01-08 at 12:11 +0100, Han-Wen Nienhuys wrote: > On Sat, Jan 7, 2023 at 10:16 PM Jonas Hahnfeld wrote: > > > > Furthermore, I'm not a fan of recommending two different ways of > > > > creating PDFs to users (once directly via Cairo and once with ps2pdf), > > > > unless we really, really have to. > > > > > > We don't really, really have to, but the advantage of dropping \epsfile > > > and \postscript isn't big either, as their Cairo implementation is not > > > complicated and can largely share code with the implementation of > > > other image formats. It may also be useful for people who still use > > > the PS/EPS output directly and not PDF output (there probably aren't > > > many for PS, but EPS might be a bit more common?). > > > > That's not really my point; if we keep markup commands that only work > > via this very specific ps2pdf conversion, we have to guarantee that > > users get the same visual output as direct PDF output. Do we want to > > support this? Does Cairo guarantee this for all possible cases that we > > run into? I highly doubt this is a good rabbit hole to go into... > > > > If we don't do that the error text of \epsfile and \postscript in the > > default PDF mode has to be "please use this ps2pdf conversion (which we > > don't even ship with our binaries), and by the way, your PDF will look > > different". That sounds horrible. > > The discussion was about deprecating \postscript and/or \eps-file. > There are 2 different ways to understand "deprecate" > > 1. "We are going to remove this command shortly; use the following > instructions to migrate to the supported XYZ command" > > 2. "We recommend against using this command in new material; use XYZ instead." > > I am arguing against definition 1. If we remove a command, especially > an open-ended one like \postscript, we are adding a new roadblock to > users that want to use the latest version of LilyPond, either because > they want better typography or because they need support for newer > platforms (eg. windows 64-bit, Apple silicon). The cost of adding this > roadblock is high for users, while its benefit (not having an ugly > error message in our code base) is small. Yes, and I want definition 1: deprecate in 2.26, remove in 3.0 (in acknowledging the cost). Because from my point of view, the "cost" is not just the error message, but the entire approach of recommending to export PS from Cairo and then use Ghostscript to get an inferior PDF. Which I would argue is entire roadblock itself, as you call it. signature.asc Description: This is a digitally signed message part
Re: Use `convert-ly -d` for LSR import?
> Please ignore this; I forgot that there is a difference between a > syntax change and missing capabilities in newer versions. s/newer/older/ Werner
Re: Use `convert-ly -d` for LSR import?
> From `convert-ly --help`: > > ``` > -d, --diff-version-update > only update \version number if file is modified > ``` > > What do you think of adding this to `makelsr.pl`? Or is there an > mandatory reason that all snippets are always tagged with the most > recent development version? Please ignore this; I forgot that there is a difference between a syntax change and missing capabilities in newer versions. Werner
Re: Missing items to make Cairo ready
On Sat, Jan 7, 2023 at 10:16 PM Jonas Hahnfeld wrote: > > > Furthermore, I'm not a fan of recommending two different ways of > > > creating PDFs to users (once directly via Cairo and once with ps2pdf), > > > unless we really, really have to. > > > > We don't really, really have to, but the advantage of dropping \epsfile > > and \postscript isn't big either, as their Cairo implementation is not > > complicated and can largely share code with the implementation of > > other image formats. It may also be useful for people who still use > > the PS/EPS output directly and not PDF output (there probably aren't > > many for PS, but EPS might be a bit more common?). > > That's not really my point; if we keep markup commands that only work > via this very specific ps2pdf conversion, we have to guarantee that > users get the same visual output as direct PDF output. Do we want to > support this? Does Cairo guarantee this for all possible cases that we > run into? I highly doubt this is a good rabbit hole to go into... > > If we don't do that the error text of \epsfile and \postscript in the > default PDF mode has to be "please use this ps2pdf conversion (which we > don't even ship with our binaries), and by the way, your PDF will look > different". That sounds horrible. The discussion was about deprecating \postscript and/or \eps-file. There are 2 different ways to understand "deprecate" 1. "We are going to remove this command shortly; use the following instructions to migrate to the supported XYZ command" 2. "We recommend against using this command in new material; use XYZ instead." I am arguing against definition 1. If we remove a command, especially an open-ended one like \postscript, we are adding a new roadblock to users that want to use the latest version of LilyPond, either because they want better typography or because they need support for newer platforms (eg. windows 64-bit, Apple silicon). The cost of adding this roadblock is high for users, while its benefit (not having an ugly error message in our code base) is small. The \postscript command is already a rabbit hole, because * it offers access to undocumented postscript commands (staff-line-thickness, draw_round_box, etc.). * it doesn't work with SVG output. * it's also a "specialist" command as writing postscript isn't for the faint of heart. However removing the rabbit-hole doesn't actually help users that have already used it in their .ly files. I am arguing that we should do what is in definition 2 (but I usually don't call this deprecate) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Use `convert-ly -d` for LSR import?
>From `convert-ly --help`: ``` -d, --diff-version-update only update \version number if file is modified ``` What do you think of adding this to `makelsr.pl`? Or is there an mandatory reason that all snippets are always tagged with the most recent development version? Werner
