Re: The final stage of my GSoC project

> > From: Jason Yip > To: lilypond-devel@gnu.org > Cc: Carl Sorensen > Bcc: > Date: Wed, 9 Aug 2023 16:55:10 -0700 > Subject: The final stage of my GSoC project > Hey everyone, > > Last week I made a draft merge request for the changes that my project > bring

The final stage of my GSoC project

merge request for my project is ready and have removed its draft status. You can view it at https://gitlab.com/lilypond/lilypond/-/merge_requests/2080 and leave feedback on it. It will be the URL of my GSoC project page. I hope that any remaining final touches for my merge request are completed

Re: Use of dev/ branches in Gitlab and GSOC

Le mercredi 31 mai 2023 à 16:09 +0200, Han-Wen Nienhuys a écrit : > On Wed, May 31, 2023 at 3:56 PM David Kastrup > <[d...@gnu.org](mailto:d...@gnu.org)> wrote: > > > > > I think I disagree in this particular context because the commitment > > from GS

Re: Use of dev/ branches in Gitlab and GSOC

ote: >> > >> >> After reading all of this, I believe I should recommend to Jason that >> he >> >> not have his gsoc repository be on the main GitLab repository for two >> >> reasons: 1) We really want the dev/ branches on GitLab to be used >&g

Re: Use of dev/ branches in Gitlab and GSOC

On Wed, May 31, 2023 at 3:56 PM David Kastrup wrote: > Han-Wen Nienhuys writes: > > > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen > > > wrote: > > > >> After reading all of this, I believe I should recommend to Jason that he > >> not have his gso

Re: Use of dev/ branches in Gitlab and GSOC

Han-Wen Nienhuys writes: > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen > wrote: > >> After reading all of this, I believe I should recommend to Jason that he >> not have his gsoc repository be on the main GitLab repository for two >> reasons: 1) We really want

Re: Use of dev/ branches in Gitlab and GSOC

On Wed, May 31, 2023 at 5:12 AM Carl Sorensen wrote: > After reading all of this, I believe I should recommend to Jason that he > not have his gsoc repository be on the main GitLab repository for two > reasons: 1) We really want the dev/ branches on GitLab to be used only for > me

Use of dev/ branches in Gitlab and GSOC

accumulation of old dev/ branches. Jason has just started his GSOC work and is jumping right into it. He's put up a branch dev/ljyip/gsoc2023-autobeaming <https://gitlab.com/lilypond/lilypond/-/tree/dev/ljyip/gsoc2023-autobeaming> on Gitlab. But it's not ready for a merge request. I've not made any

Re: Fix Lilypond Beaming GSOC Project

>>> One thing that concerns me is that generating tests takes a long >>> time (`make test`). > > Besides using option `-jX` from make, [...] Ah, and also look into the environment variable `CPU_COUNT` used by LilyPond's build system. For example, I usually do a documentation build with ```

Re: Fix Lilypond Beaming GSOC Project

>> One thing that concerns me is that generating tests takes a long >> time (`make test`). Besides using option `-jX` from make, I also suggest that you use 'ccache' to speed up the C++ compiler. https://ccache.dev/ This doesn't directly help with 'make test', though. Werner

Re: Fix Lilypond Beaming GSOC Project

to One way to meet goals 2 and 3 would be for you to prepare a patch that may or may not be related to your GSOC project, and get it through the code review process and into the countdown. It could be a patch as simple as a documentation patch. Perhaps it would be good for you to search the issues li

Re: Fix Lilypond Beaming GSOC Project

For what it's worth, I compile LilyPond on ArchLinux pretty much every other day : pikaur -S lilypond-git --rebuild I've change this line (33?) in the PKGBUILD to point to my local repository : source=(lilypond::git+file:///my/very/own/repo/lilypond-git) HTH, -- Pierre-Luc Gauthier Le mar.

Re: Fix Lilypond Beaming GSOC Project

Le mardi 16 mai 2023 à 10:34 -0700, Jason Yip via Discussions on LilyPond development a écrit : > One  thing that concerns me is that generating tests takes a long time (`make  > test`). I would need to supervise my computer from overheating during > the execution of that command. I wonder if

Re: Fix Lilypond Beaming GSOC Project

and may have reduced communication until May 15th. But I'll be able to focus more on GSoC Bonding Period between the 16th and the start of the project. I get the "quite busy" part of this.  I just finished a semester at the University, and it was a very busy time due to grad

Re: Fix Lilypond Beaming GSOC Project

Le samedi 06 mai 2023 à 22:27 +, Jason Yip a écrit : > I got it working on my Arch Linux after trial and error with ./configure. > Here are the Arch Linux package names that translate to what Lilypond needs > (I didnt include package names that I already > had, so obviously there's Python,

Re: Fix Lilypond Beaming GSOC Project

I got it working on my Arch Linux after trial and error with ./configure. Here are the Arch Linux package names that translate to what Lilypond needs (I didnt include package names that I already had, so obviously there's Python, ghostscript, etc.): * dblatex (optional, configure script keeps

Re: Fix Lilypond Beaming GSOC Project

d communication until May 15th. But I'll be able to focus more on > GSoC Bonding Period between the 16th and the start of the project. > > I get the "quite busy" part of this. I just finished a semester at the University, and it was a very busy time due to grading. I'll look forwa

Re: Fix Lilypond Beaming GSOC Project

Hi, I'm adding back the list in CC (did you forget it? we strongly prefer on-list replies on general to keep everything public, as in most FOSS projects). Le jeudi 04 mai 2023 à 22:03 -0500, Jason Yip a écrit : > I didn't have much time to learn about specific Lilypond dependencies  > and what

Re: Fix Lilypond Beaming GSOC Project

Hi Jason, congratulations on your acceptance. > As for now, I have already set up a Lilypond development environment. It's > the LilyDev docker image (I actually use podman instead of docker). I was > able to compile Lilypond on it, make a fix, then build that fix. I haven't > tried running

Re: Fix Lilypond Beaming GSOC Project

Hi Carl and fellow developers! I'm excited to work with all of you on Lilypond and hope that we can complete the project! I'll be quite busy with the end of my university semester and may have reduced communication until May 15th. But I'll be able to focus more on GSoC Bonding Period

Fix Lilypond Beaming GSOC Project

Dear Jason, As you know by now, you've been selected to complete a GSOC project on improving LilyPond beaming. Congratulations! Your proposal was of very high quality, and we are anxious to have you starting to work with us. The next three weeks constitute the Community Bonding period. I hope

Fw: [gnu-soc] GNU accepted in GSOC 2023

We should now revise our GSoC page... Werner --- Begin Message --- Hello people! The GNU Project has been accepted as a mentoring organization in the Google Summer of Code program, 2023. This is what we have to do now: - If your GNU program wants to participate, please send project

Re: [gnu-soc] GNU GSOC 2023 application

ne with a small and > one with a big 'hole' within it. > > Difficulty: easy/medium > Size: 175h/350h > Required skills: MetaFont, C++, good eye for details > Contact: 'lilypond-devel@gnu.org' mailing list > (https://lists.gnu.org/mailman/listinfo/lilypond-devel)

Re: [gnu-soc] GNU GSOC 2023 application

' mailing list (https://lists.gnu.org/mailman/listinfo/lilypond-devel) Recommended knowledge: basic LilyPond knowledge More GSoC ideas: https://lilypond.org/google-summer-of-code.html

Re: [Jose E. Marchesi] [gnu-prog-discuss] GNU GSOC 2023 application

update the GSoC page on lilypond.org with the newest details such as the project size (and also move the other projects to the Attic). Best, Jean signature.asc Description: This is a digitally signed message part

[Jose E. Marchesi] [gnu-prog-discuss] GNU GSOC 2023 application

Forwarded from gnu-prog-disc...@gnu.org: --- Begin Message --- Hi hackers. Please see below. If you are interested in participating with your GNU program in GSOC 2023 under the umbrella of GNU, please subscribe to summer-of-c...@gnu.org and send the requested information for ideas. Thanks

Re: GSoC 2023

>> umbrella and get slots from the there. > > > > Hmm, this probably is no longer correct. I now remember that GNU was > > rejected as an GSoC organization in 2021, > > > (Given https://www.gnu.org/proprietary/malware-google.html > I am actually surprised that GNU to be a

Re: GSoC 2023

er correct. I now remember that GNU was > rejected as an GSoC organization in 2021, (Given https://www.gnu.org/proprietary/malware-google.html I am actually surprised that GNU to be accepted for the previous years...) OpenPGP_signature Description: OpenPGP digital signature

Re: GSoC 2023

On 03/02/2023 16:16, Jean Abou Samra wrote: > If we want to apply, we really need a solid list of projects. > Peter, Carl, Abraham, ping, can you please confirm whether you > are still willing or not to act as mentors for the projects > listed on https://lilypond.org/google-summer-of-code.html ?

Re: GSoC 2023

er correct. I now remember that GNU was > rejected as an GSoC organization in 2021, and I couldn't find any > hints in > > https://lists.gnu.org/archive/html/summer-of-code/ > > that there is any activity for a GNU umbrella in 2022 or 2023. > > So it seems that LilyPond

Re: GSoC 2023

> Aah, thanks, now I remember: LilyPond, being part of GNU, doesn't have > to apply separately (or should we?); instead, we are using the GNU > umbrella and get slots from the there. Hmm, this probably is no longer correct. I now remember that GNU was rejected as an GSoC organizatio

Re: GSoC 2023

>> Who did the LilyPond's registration as an organization last time? > > I remember Urs Liska being the main facilitator for Google Summer of > Code work. > > >

Re: GSoC 2023

On 2/3/2023 1:17 AM, Werner LEMBERG wrote: Who did the LilyPond's registration as an organization last time? I remember Urs Liska being the main facilitator for Google Summer of Code work.

Re: GSoC 2023

>> AFAIK, the LilyPond's GSoC pages are up to date, but maybe some >> minor adjustments or additions are necessary/useful, so please have >> a look! >> >> https://lilypond.org/google-summer-of-code.html > > I think one point that could be improved

Re: GSoC 2023

On Mon, 2023-01-30 at 08:55 +, Werner LEMBERG wrote: > The deadline for registering LilyPond as mentor organization for GSoC > 2023 is February 7th.  Do we want to participate? > > Who did the registration the last time?  If necessary, I'm willing to > do the registering proc

Re: GSoC 2023

Jean Abou Samra writes: > On 30/01/2023 09:55, Werner LEMBERG wrote: >> >> The deadline for registering LilyPond as mentor organization for GSoC >> 2023 is February 7th. Do we want to participate? > > > I won't mentor anyone (I wouldn't feel comfortable doing thi

Re: GSoC 2023,Re: GSoC 2023

ond. Thanks, but it's not about the technical support: if we have a GSoC student, I am prepared to assist them with technical issues on this mailing list and GitLab issues/MRs, just like with all new contributors. There is just an additional aspect to mentoring, namely overseeing the planning, making

Re: GSoC 2023,Re: GSoC 2023

riants of font glyphs' a 'medium' project. Another thing is that GSoC projects are no longer restricted to three months. The time interval can be stretched up to six months if desired by the student and/or the mentor. Werner

Re: GSoC 2023

On 30/01/2023 09:55, Werner LEMBERG wrote: > > The deadline for registering LilyPond as mentor organization for GSoC > 2023 is February 7th. Do we want to participate? I won't mentor anyone (I wouldn't feel comfortable doing this for someone roughly my age), but if there is

GSoC 2023

The deadline for registering LilyPond as mentor organization for GSoC 2023 is February 7th. Do we want to participate? Who did the registration the last time? If necessary, I'm willing to do the registering process if we agree on participation. AFAIK, the LilyPond's GSoC pages are up to date

Re: GSoC page

Thanks for the replies, I've opened https://gitlab.com/lilypond/lilypond/-/merge_requests/1599 Best, Jean

Re: GSoC page

> - Variants of font glyphs: Werner, is this still relevant? Yes. Werner

Re: GSoC page

Hi all, > - Support for style sheets: Abraham, Kieren? Definitely still available to be, and interested in being, the “Community Mentor” on that! Thanks, Kieren.

GSoC page

Hi, The page https://lilypond.org/google-summer-of-code.html look somewhat outdated, it says it's for GSoC 2018, and there is still the SMuFL project taken by Owen for example. Can we update it? - SMuFL: taken by Owen, should be removed - Variants of font glyphs: Werner, is this still

GSoC 2021

One thing we all need to be aware of is that GSoC has reduced the coding period by half for 2021. Projects are now about 175 hours instead of about 350 hours. As we think about projects, we need to be thinking about the reduced scope. Thanks, Carl

Re: GSoC 2020 update: (hopefully) final commits made; testing time

> Here's another stab at glyphnames.json.txt, given all this new information: > > glyphnames.json is a part of the Standard Music Font Layout > (SMuFL) specification, version 1.3. It was retrieved from > https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under > the W3C Final

Re: GSoC 2020: Unexpected "regressions"...

> I meant re-committing my first commit with the fix, then rebasing > the dev/lamb/GSoC-2020-final branch on top of it to keep my history > pretty. In general, this is the ideal solution, since it cleans up your branch. However, ... > Would you rather I just made

Re: GSoC 2020: Unexpected "regressions"...

On Sat, Aug 29, 2020 at 5:07 PM Carl Sorensen wrote: > As long as all of your commits build successfully, it's not a big deal if > there is a regression problem in the middle, IMO. I'd just add a commit at > the end and call it good. OK. (I already did it the other way, but for any other

Re: GSoC 2020: Unexpected "regressions"...

u should simply add another commit to your branch to fix > this, then yes :-) > Ah. No, I meant re-committing my first commit with the fix, then rebasing the dev/lamb/GSoC-2020-final branch on top of it to keep my history pretty. Would you rather I just made a new commit? --Owen

Re: GSoC 2020: Unexpected "regressions"...

do it?) > > If you mean you should simply add another commit to your branch to fix > this, then yes :-) > Ah. No, I meant re-committing my first commit with the fix, then rebasing the dev/lamb/GSoC-2020-final branch on top of it to keep my history pretty. Would you rather I just made a new commit? --Owen

Re: GSoC 2020 update: (hopefully) final commits made; testing time

On Sat, Aug 29, 2020 at 3:09 AM Werner LEMBERG wrote: > > > So, glyphnames.json.txt would look like this? > > > > glyphnames.json, created by Daniel Spreadbury, was retrieved from > > https://github.com/w3c/smufl on DD Mon . It is licensed under > > the W3C Community Contributor

Re: GSoC 2020 update: (hopefully) final commits made; testing time

> So, glyphnames.json.txt would look like this? > > glyphnames.json, created by Daniel Spreadbury, was retrieved from > https://github.com/w3c/smufl on DD Mon . It is licensed under > the W3C Community Contributor License Agreement and the W3C Final > Specification Agreement. Looks

Re: GSoC 2020: Unexpected "regressions"...

> Ah! It looks like the issue is in line 12 of palm-mute.ly: > > e8^\markup { \musicglyph "noteheads.u2do" = palm mute } > > Here, \musicglyph is looking for noteheads.u2do, which I combined > with .d2do to make .s2do. Changing the string to "noteheads.s2do" > makes this regression test

Re: GSoC 2020 update: (hopefully) final commits made; testing time

On Mon, Aug 24, 2020 at 1:07 AM Werner LEMBERG wrote: > * Who has written the file `glyphnames.json`? It lacks a copyright > header. If this is a non-lilypond file copied verbatim, please add > a separate file (say, `glyphnames.json.txt`) that gives all the > details: author, origin,

Re: GSoC 2020: Unexpected "regressions"...

On Fri, Aug 28, 2020 at 3:00 AM Michael Käppler wrote: > I cannot reproduce this on my machine. > All right. Thanks for giving it a try. Han-Wen, I'll take your advice and ignore this issue for the time being. > What I see are differences in input/regression/tablature-letter.ly > (which I

Re: GSoC 2020: Unexpected "regressions"...

On Fri, Aug 28, 2020 at 9:03 AM Owen Lamb wrote: > > Hi all, > > I've encountered a couple of unexpected regressions for my first commit. > The first one was an issue with tablature stems, which I was able to fix. > The other, however, is baffling to me. > > It appears that musicxml2ly creates

Re: GSoC 2020: Unexpected "regressions"...

Am 28.08.2020 um 09:53 schrieb Michael Käppler: Am 28.08.2020 um 09:03 schrieb Owen Lamb: Hi all, I've encountered a couple of unexpected regressions for my first commit. The first one was an issue with tablature stems, which I was able to fix. The other, however, is baffling to me. It

Re: GSoC 2020: Unexpected "regressions"...

Am 28.08.2020 um 09:03 schrieb Owen Lamb: Hi all, I've encountered a couple of unexpected regressions for my first commit. The first one was an issue with tablature stems, which I was able to fix. The other, however, is baffling to me. It appears that musicxml2ly creates slightly different .ly

GSoC 2020: Unexpected "regressions"...

Hi all, I've encountered a couple of unexpected regressions for my first commit. The first one was an issue with tablature stems, which I was able to fix. The other, however, is baffling to me. It appears that musicxml2ly creates slightly different .ly files between the two commits, for musicxml

Re: GSoC 2020: backwards compatibility

ibility is important enough that we should > > probably have it before merging the code into master. > > Exactly. However, ... > > > I don't think it's necessary to do it before the deadline, as long > > as you will commit to do it afterwards. > > ... this doesn't dire

Re: GSoC 2020: backwards compatibility

master. Exactly. However, ... > I don't think it's necessary to do it before the deadline, as long > as you will commit to do it afterwards. ... this doesn't directly influence your project. > I believe you can successfully pass GSoC with a branch that is not > yet merged into mas

Re: GSoC 2020: backwards compatibility

ter. In my opinion, it would be best if LilyPond would work with the 'old' Emmentaler (and hence any of the older fonts as well). I don't think it's necessary to do it before the deadline, as long as you will commit to do it afterwards. I believe you can successfully pass GSoC with a branch t

GSoC 2020: backwards compatibility

Hi all! Daniel drew my attention to the fact that my work doesn't keep backwards compatibility with other fonts encoded in the LilyPond manner, such as Gonville. He made a good point--it's definitely worth it to continue supporting the old format until Emmentaler reaches a reasonable SMuFL or

Re: GSoC 2020 update: (hopefully) final commits made; testing time

> I've reordered and rebased my code, and it is now up to date with > the current master. I've just published the new branch to GitLab as > dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only > nine commits now, instead of over a hundred, and they're ordered in &g

Re: GSoC 2020 update: (hopefully) final commits made; testing time

>> At the same time, I'll write docs for my work. I figure I'll make >> nine documentation commits, one for each code change commit. Hmm. Maybe I've misunderstood you. What's actually missing are documentation strings *within* the commits. For example, the commit Add smufl data to feta

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG: > > I've reordered and rebased my code, and it is now up to date with > > the current master. I've just published the new branch to GitLab > as > > dev/lamb/GSoC-2020-final if you'd like to give it a look.

Re: GSoC 2020 update: (hopefully) final commits made; testing time

> I've reordered and rebased my code, and it is now up to date with > the current master. I've just published the new branch to GitLab as > dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only > nine commits now, instead of over a hundred, and they're ordered in &g

GSoC 2020 update: (hopefully) final commits made; testing time

--i.e. Friday--if possible. I've reordered and rebased my code, and it is now up to date with the current master. I've just published the new branch to GitLab as dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only nine commits now, instead of over a hundred, and they're ordered

Re: GSoC 2020 update, Aug 15 (the final stretch!)

On Mon, Aug 17, 2020 at 12:13 AM Werner LEMBERG wrote: > > I wonder whether it is possible to improve legibility: Could you > modify the code so that whitespace in the strings gets ignored? I > consider > > "accidentalFlat & accidentalKucukMucennebFlat & accidentalFlatArabic" > > much more

Re: GSoC 2020 update, Aug 15 (the final stretch!)

e > right term for it. I don't plan to add any new code to the official > GSoC project; instead, I'll be focusing on making my code easily > reviewable, updating docs, and summarizing my work. OK. > That said, summarizing looks like it'll be a beast. I suppose if I'm going > to start

GSoC 2020 update, Aug 15 (the final stretch!)

h--just search for GSoC-2020 TODO. I believe now is the time for a "feature freeze," if that's the right term for it. I don't plan to add any new code to the official GSoC project; instead, I'll be focusing on making my code easily reviewable, updating docs, and summarizing my work. That said

Re: GSoC 2020 update: July 25

Hi Owen, >> Well, of all the new things I'm experiencing in this job, I'm starting to >> experience burnout. As someone who experienced almost-complete (i.e., Stage 11 of 12) burnout syndrome in 2016, I want to bring your attention to this

Re: GSoC 2020 update: Aug 7

test as little as possible to make debugging easier. >- Once everything checks out, as Jean suggested, I'll write a > blog post on lilypondblog.org, summarizing my work, what I > learned on the way, and where things need to head next for > SMuFL on LilyPond. Yes... >

Re: GSoC 2020 update: Aug 7

emely useful, and it > will remain so even if at the end of GSoC it's not in a state that > every user can use it out-of-the-box. > OTOH if I understood the recent discussion about merging and rebasing > correctly your code itself has not been reviewed at all so far? In that > case you s

Re: GSoC 2020: blot diameter and positioning of flags

Late to the party, but you are right on the money, Owen. This is why in bmusicfonts I manually cut the Bravura flags to match Emmentaler's when creating a LilyPond-native font from Bravura.

Re: GSoC 2020: blot diameter and positioning of flags

On Thu, Aug 6, 2020 at 9:03 PM Carl Sorensen wrote: > > I am a bit concerned that we are talking about eliminating some of what I > think are superior design decisions of LilyPond in order to be SMuFL > compliant. I prefer the convention of attaching the flag to the center of > the stem as

Re: GSoC 2020 update: Aug 7

features or seem crucial. As far as I can see your work so far has been extremely useful, and it will remain so even if at the end of GSoC it's not in a state that every user can use it out-of-the-box. OTOH if I understood the recent discussion about merging and rebasing correctly your code

Re: GSoC 2020 update: Aug 7

ference between > LilyPond's and SMuFL's treatment of flags. > > I've slightly modified my general project approach, > > ... > > The school year is almost upon us here in AZ, and, as I mentioned at > the > beginning of summer, there'll be some overlap with GSoC. I'll be o

GSoC 2020 update: Aug 7

be some overlap with GSoC. I'll be out for the count for a couple weekdays next week, so I'll pick up Saturday to make up for it. After that, I expect to be doing more night/weekend hours as classes start up the following week on the 20th. My plan is largely the same as it was last week. If you have

Re: GSoC 2020: blot diameter and positioning of flags

On Thu, Aug 6, 2020 at 9:03 PM Carl Sorensen wrote: > > I am a bit concerned that we are talking about eliminating some of what I > think are superior design decisions of LilyPond in order to be SMuFL > compliant. I prefer the convention of attaching the flag to the center of > the stem as

Re: GSoC 2020: blot diameter and positioning of flags

On Thu, Aug 6, 2020 at 2:57 PM Owen Lamb wrote: > On Wed, Aug 5, 2020 at 10:57 PM Werner LEMBERG wrote: > > > > > Well, LilyPond's solution is more versatile... > > > > I agree, to a point. It's more versatile for the user, but not necessarily > for the font designer. At any rate, it's not

Re: GSoC 2020: blot diameter and positioning of flags

On 06/08/2020 22:57, Owen Lamb wrote: > Sure! I've lined the stems up with a staff line for clarity and included > Frescobaldi's display-grob-anchors.ily, slightly modified to make sure the > anchor dots don't dwarf the actual grobs. As you can see, Bravura's flags > are expected to be anchored

Re: GSoC 2020: blot diameter and positioning of flags

On Wed, Aug 5, 2020 at 10:57 PM Werner LEMBERG wrote: > > Well, LilyPond's solution is more versatile... > I agree, to a point. It's more versatile for the user, but not necessarily for the font designer. At any rate, it's not exactly something we can overturn when the specification has already

Re: GSoC-2020 update: Jul 31

Hi Owen, Le 6 août 2020 à 03:19, Owen Lamb a écrit : Wow! Thanks everyone... even if a lot of this went over my head. I've never rebased before, so I can't say what would be the better option. There are many tutorials on the Web about this, for instance

Re: GSoC 2020: blot diameter and positioning of flags

> Emmentaler's flag glyphs are minimal: they deliberately don't > overwrite a stem's tip, only overlapping with the stem in a thin, > rectangular area [...] > > However, SMuFL expects scoring programs to use plain rectangle primitives > for drawing stems. With this in mind, Bravura's flags

Re: GSoC-2020 update: Jul 31

Wow! Thanks everyone... even if a lot of this went over my head. I've never rebased before, so I can't say what would be the better option. At any rate, my understanding is that I'll organize my commits near the end of the project to make sure everything is reviewable, correct? If that's the

GSoC 2020: blot diameter and positioning of flags

Hi all, I've been working on making flags appear at the correct position for both Emmentaler and Bravura, and I've hit a snag. Emmentaler's flag glyphs are minimal: they deliberately don't overwrite a stem's tip, only overlapping with the stem in a thin, rectangular area (see the attached

Re: GSoC-2020 update: Jul 31

On Fri, Jul 31, 2020 at 9:59 PM Werner LEMBERG wrote: > A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do > you change from the (IMHO preferable) `-` to `_` in the file name? I > consider `_` an abomination that is only necessary because `-` is not > a valid character in

Re: GSoC-2020 update: Jul 31

Thanks for the tip! I just filed issue #4417 on their repo. (I originally was going for the mailing list because I thought there might be something wrong with our font files, not FontForge itself, and it'd be premature to file a bug report. But I guess if FontForge can't fail gracefully and tell

Re: GSoC-2020 update: Jul 31

(Forgot to reply-all, so sending this to the mailing list as well.) Hi Daniel, I see what you mean. Judging from the example you offered, however, I believe the issue is not one of scaling, but of origin misplacement. When zoomed in, my current reproduction of Bravura appears to be too far to

Re: GSoC-2020 update: Jul 31

Am Samstag, den 01.08.2020, 23:31 +0200 schrieb Jean Abou Samra: > While I generally prefer merging over rebasing, since we enforce an > all-fast-forward policy for merging to master, I think we should rebase > here. My reasoning is that you put in more information when resolving > conflicts

Re: GSoC-2020 update: Jul 31

Well, there's a good reason that gitlab has a big, fat 'rebase' button... >> >> Not sure about the meaning of your message: this button shows up >> because we enabled it as a project-wide setting. To my knowledge, >> the default and most common strategy is merging. Exactly! It's our

Re: GSoC-2020 update: Jul 31

Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra : >Hi everyone, > >Le 01/08/2020 à 18:19, Urs Liska a écrit : >> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : > Another issue: Maybe it makes sense if you try to rebase your > branch from time to time. Really

Re: GSoC-2020 update: Jul 31

Hi everyone, Le 01/08/2020 à 18:19, Urs Liska a écrit : Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : Another issue: Maybe it makes sense if you try to rebase your branch from time to time. Really rebase? Yes, I favour rebasing over merging since the former causes a `prettier'

Re: GSoC-2020 update: Jul 31

Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : >>> Another issue: Maybe it makes sense if you try to rebase your >>> branch from time to time. >> >> Really rebase? > >Yes, I favour rebasing over merging since the former causes a >`prettier' git commit tree. > >> This would be a case

Re: GSoC-2020 update: Jul 31

>> Another issue: Maybe it makes sense if you try to rebase your >> branch from time to time. > > Really rebase? Yes, I favour rebasing over merging since the former causes a `prettier' git commit tree. > This would be a case where "general wisdom" argues against modifying > pushed commits.

Re: GSoC-2020 update: Jul 31

Am 1. August 2020 06:59:16 MESZ schrieb Werner LEMBERG : > >> In the meantime, I've gotten Bravura glyphs to appear on the page! > >Congrats! > >A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do >you change from the (IMHO preferable) `-` to `_` in the file name? I >consider

Re: GSoC-2020 update: Jul 31

> In the meantime, I've gotten Bravura glyphs to appear on the page! Congrats! A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do you change from the (IMHO preferable) `-` to `_` in the file name? I consider `_` an abomination that is only necessary because `-` is not a

Re: GSoC-2020 update: Jul 31

Also, the best way to get at the FF devs is by opening an issue on GitHub, where there are no issues with attachments. On 8/1/20 12:34 AM, Daniel Benjamin Miller wrote: Great work, Owen, and I'll be happy to use your implementation of smufl in LilyPond, instead of having to deal with my own

Re: GSoC-2020 update: Jul 31

Great work, Owen, and I'll be happy to use your implementation of smufl in LilyPond, instead of having to deal with my own manual Bravura conversions. But the flags as they stand are not displaying at the same scale as they do in Bravura when output by Dorico. See this file for a sample:

  1   2   3   4   5   6   7   >