A few days ago, a changeset was submitted to merge some fonts related to something called the "Google DocRepair project": https://gerrit.libreoffice.org/c/core/+/169765 The fonts for which substitutes were merged are: Agency FB Baskerville Old Face Berlin Sans FB Cooper Black Lucida Calligraphy Lucida Grande Lucida Handwriting To my knowledge, all of these fonts are only used rarely by office document authors. Some of them have been prevalent in print in the past (like Baskerville and Cooper Black), others have been used in desktop environment UI (like Lucida Grande). Agency FB was apparently used in the Crysis 2 game... Anyway, I believe none of these would merit bundling with LibreOffice (and hey won't help with "doc repair") - let alone a set of fonts whose only merit is being metrically equivalent to these. Let me quote the relevant comment exchange on the Changeset: > Caolan: https://github.com/docrepair-fonts These are various fonts that google has created to provide metrically equivalent fonts to fonts available in MSOffice to improve document layout for MSOffice compatibility. Similar to "Liberation Serif" for Times New Roman and "Carlito" for Calibri > > Ilmari: Sure, but why now? Do we have statistics on how widespread their use is? > > Andras Timar: > > Sure, but why now? > Because we discovered these fonts now. > * Do we have statistics on how widespread their use is? > I assume Google did the research and decided to develop these fonts Unfounded assumption :-( Please undo the Changeset and unbundle these fonts.
Yes, I scratched my head about this font addition when I saw it. Is the "Google DocRepair project" an active effort we need to participate in? Included fonts seem a bit obscure, especially as we'd clobbered the Adobe OFL Source* font families ([1][2])--presumably in favor of wider i18n support of Noto font offerings. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/143645 [2] https://gerrit.libreoffice.org/c/core/+/143665
I propose to grep through the files in our crash report corpus to find out how many of them contain these fonts.
Created attachment 195300 [details] Font statistics from crashtesting document corpus Downloaded docx, odg, odp, ods, odt, pptx and xlsx files from bugtrackers and forums directories of the crashtesting corpus. Total number of documents I investigated: $ find . -type f \( -name '*.docx' -o -name '*.odg' -o -name '*.odp' -o -name '*.ods' -o -name '*.odt' -o -name '*.pptx' -o -name '*.xlsx' \) | wc -l 607790 Xlsx files dominate, their share being 500633. I unzipped all of them in this style: find . -name '*.xlsx' | while read file; do unzip -o "$file" -d "${file%.*}" done Some of the xml files had permission issues, so I had to fix them with sudo find . -name '*.xml' -exec chmod 644 {} \; I got the usage stats by using ripgrep and filtering out duplicates with sort and uniq: rg --files-with-matches 'Agency FB' . -g '*.xml' | cut --delimiter "/" --fields=2,3,4 | sort | uniq -u > agency_fb.txt Agency FB, 246 files Baskerville Old Face, 303 files Berlin Sans FB, 319 files Cooper Black, 105 files Lucida Calligraphy, 88 files Lucida Grande, 201 files Lucida Handwriting, 103 files I guess that's not nothing, but seems to indicate that the chances of running into these fonts in the wild is pretty low. It would be interesting to hear, if the clients of companies have signalled a need for replacement fonts or what other motivators there could be for shipping them.
(In reply to Buovjaga from comment #3) > Agency FB, 246 files > Baskerville Old Face, 303 files > Berlin Sans FB, 319 files > Cooper Black, 105 files > Lucida Calligraphy, 88 files > Lucida Grande, 201 files > Lucida Handwriting, 103 files The most popular typeface appears in 319 / 607790 files, or 0.05% of the files. If we take out the xlsx'es (after all - who uses fancy fonts in spreadsheets?), and assume we've not removed any of the appearances - it's around 0.3% . That is actually a bit more than I expected - but still not worth the bundling IMHO. (If we could legitimately associate these typefaces with some geographic or language community that's small, I might have dropped my objection. Also, instead of bundling, we could get someone to work on bug 159950 and offer font download on-demand for these.)
Might also find a bunch of more uses in the binary formats too, but trickier to scan inside there I guess. Google found it worthwhile to create these metrically equivalent fonts for compatibility purposes.
(In reply to Caolán McNamara from comment #5) > Google found it worthwhile to create these > metrically equivalent fonts for compatibility purposes. If we knew what these purposes were, and what they wanted compatibility with - we could consider that. But on principle, it is not reasonable for us to add files to our distribution just because we were told someone at (the 180,000-person company) Google decided they were useful... :-(
(In reply to Eyal Rozenberg from comment #6) > (In reply to Caolán McNamara from comment #5) > > Google found it worthwhile to create these > > metrically equivalent fonts for compatibility purposes. > > If we knew what these purposes were, and what they wanted compatibility with > - we could consider that. But on principle, it is not reasonable for us to > add files to our distribution just because we were told someone at (the > 180,000-person company) Google decided they were useful... :-( Indeed. There is no documentation, blog post or anything explaining how this DocRepair project came about. Google is all about data mining, so surely they might give an explanation on why they decided to do this.
(In reply to Buovjaga from comment #7) > (In reply to Eyal Rozenberg from comment #6) > > (In reply to Caolán McNamara from comment #5) > > > Google found it worthwhile to create these > > > metrically equivalent fonts for compatibility purposes. > > > > If we knew what these purposes were, and what they wanted compatibility with > > - we could consider that. But on principle, it is not reasonable for us to > > add files to our distribution just because we were told someone at (the > > 180,000-person company) Google decided they were useful... :-( > > Indeed. There is no documentation, blog post or anything explaining how this > DocRepair project came about. Google is all about data mining, so surely > they might give an explanation on why they decided to do this. Is it even a google sponsored project? Looks to be on github https://github.com/orgs/docrepair-fonts/repositories Look in the repos of the individual font for replacement/usage goals, most with intent to avoid reflow of OOXML (ISO 29500) documents. To obtain more details, and an idea if TDF and our LibreOffice/Document Liberation projects should actively participate, i.e. a home for 'OpenSymbol' perhaps someone might contact project lead, Adam Twardoch. Who does not look to be a Google employee ;-)
(In reply to V Stuart Foote from comment #8) > Is it even a google sponsored project? Looks to be on github > https://github.com/orgs/docrepair-fonts/repositories > > Look in the repos of the individual font for replacement/usage goals, most > with intent to avoid reflow of OOXML (ISO 29500) documents. > > To obtain more details, and an idea if TDF and our LibreOffice/Document > Liberation projects should actively participate, i.e. a home for > 'OpenSymbol' perhaps someone might contact project lead, Adam Twardoch. Who > does not look to be a Google employee ;-) https://docrepair-fonts.github.io/ says This repository contains documentation about the DocRepair project. TBD.
(In reply to V Stuart Foote from comment #8) > To obtain more details, and an idea if TDF and our LibreOffice/Document > Liberation projects should actively participate, i.e. a home for > 'OpenSymbol' perhaps someone might contact project lead, Adam Twardoch. Who > does not look to be a Google employee ;-) Adam confirmed to me that the development work on The DocRepair Project fonts was indeed funded by Google Fonts.
Heiko conformed without explanation. Which does not seem justified IMO as this is not self-explanatory. IIUC there are 2 arguments agains: rarely used and Google sponsored. Regardless if rarely, any metric compatible font is useful IMO. Font replacement is significant weakness of LO in real world where majority unfortunatelly uses MSO. Instead of discussing how to better replace other common fonts, for example Aptos or Segoe family, here is discussed how to step back. As for Google, that is Sign of the Beast, together with others, and that is mostly about tehcnology, etc. But in this specific example, I do not see valid explanation on the adverse effects of using these fonts.
(In reply to Timur from comment #11) > IIUC there are 2 arguments agains: rarely used and Google sponsored. > Regardless if rarely, any metric compatible font is useful IMO. It is useful, but not meaningfully useful. Remember we used to bundle the Source fonts - which are quite useful; and we unbundled them, since they are not critically useful. > Font > replacement is significant weakness of LO in real world where majority > unfortunatelly uses MSO. This would not meaningfully help us with font replacement as MSO users do not get these fonts bundled with MSO, nor with MS Windows, nor with MacOS, nor with Linux. In fact, it would probably not _ever_ help us, relative to MSO. > Instead of discussing how to better replace other > common fonts, for example Aptos or Segoe family, here is discussed how to > step back. By this logic, we should bundle thousands of metrically-compatible fonts, to cover any font which has even a marginal frequency in users' documents.
(In reply to Timur from comment #11) > Heiko conformed without explanation. Which does not seem justified IMO as > this is not self-explanatory. > IIUC there are 2 arguments agains: rarely used and Google sponsored. > Regardless if rarely, any metric compatible font is useful IMO. Font > replacement is significant weakness of LO in real world where majority > unfortunatelly uses MSO. Instead of discussing how to better replace other > common fonts, for example Aptos or Segoe family, here is discussed how to > step back. > As for Google, that is Sign of the Beast, together with others, and that is > mostly about tehcnology, etc. But in this specific example, I do not see > valid explanation on the adverse effects of using these fonts. That's not a correct summary of the arguments. Arguments against: - rarely used - we should be really selective on what fonts we bundle - we should rather implement a way to download recommended fonts Arguments for: - Google sponsored the work, so Google must have some statistics on the use of these fonts that we can't access (this is the reason I did my own investigation based on crash testing corpus) Nobody is saying that Google's involvement would be a negative. Google sponsoring an alternative to Aptos would be welcomed with open arms.
(In reply to Buovjaga from comment #13) > - Google sponsored the work, so Google must have some statistics on the use > of these fonts that we can't access (this is the reason I did my own > investigation based on crash testing corpus) Note that we don't even know that Google _claims_ that these fonts are commonly used, nor that the project runners / font designers make this claim. If and when they do, we can consider it. But they are unlikely to IMNSHO. Also note, that there has not been work on that project since June of last year (at least - no commits to the font repositories.)
in any event, an additional configure flag --with-docrepair-fonts might square the circle here wrt allowing builds to opt in/out of bundling these fonts
Great suggestion. Syntax like --enable-noto-font. And that should be applied also to Source fonts, instead of removing.
(In reply to Caolán McNamara from comment #15) Are you sure? I mean, that squared-circle means, that 99% of LO users don't have these fonts. So, what is the benefit of them being in the source tree? Someone who wants to have LO and Noto fonts, or LO and Source fonts, or LO and the DocProject fonts - just downloads LO and also gets the fonts. It's easier than a custom build of LO --with-extra-stuff. (And there's bug 159950 for making this even easier and simpler for the user). Moreover - the question is that of process no less than the matter itself; the order of things should be: First we need a reasonable argument in favor of bundling something with LO; then that argument is evaluated; then, if accepted, there's a commit. Here, we rushed to commit, and now we're mulling over the justification after the fact. I believe I am not speculating too wildly to assume, that if this discussion was had earlier - the commit would not happen right now while we are undecided (and IIANM leaning towards rejection). Now, if this had already been released, and users had been relying on these fonts being in LO for a while - then the argument could have been made that it's a "done deal" and we should leave them in.
Eyal, et. al.: if you take the responsibility for your decision, feel free to do whatever you want in master. You can revert my patch, or add a configure switch, I don't mind at all. My job is done, it was to include these fonts. In worst case I have to cherry-pick again in future Collabora branches.
(In reply to Andras Timar from comment #18) > Eyal, et. al.: if you take the responsibility for your decision, feel free > to do whatever you want in master. You can revert my patch, or add a > configure switch, I don't mind at all. My job is done, it was to include > these fonts. In worst case I have to cherry-pick again in future Collabora > branches. Ouch, that's a bit harsh. Of course it is Collabora's choice--but equally "Devs decide" is a reasonable mantra--long followed and supported in the project--for the broader community. We certainly don't want Collabora's efforts to diverge from master needlessly. I don't agree with Eyal's naive perception that the project is overly bound by "process", but there are reasonable questions as to adoption/participation in FOSS projects supporting OOXML (ISO/IEC 29500) interests over ODF. Font support choices are a sore point for many in the community, and this bundling came from "out of the blue", so I get the concern and would love a comment on what drove the commit. But frankly I'm much more concerned with the lack of progress on an 'Aptos' substitute. @Heiko, you set this to NEW but I've reverted that as I don't see that a revert of https://gerrit.libreoffice.org/c/core/+/169765 needs to happen.
(In reply to V Stuart Foote from comment #19) > But frankly I'm much more concerned with the lack of progress on an 'Aptos' > substitute. It's on the table. > @Heiko, you set this to NEW but I've reverted that as I don't see that a > revert of https://gerrit.libreoffice.org/c/core/+/169765 needs to happen. New is not an immediate revert. You and others raised good questions and the ticket is in NI state.
(In reply to Andras Timar from comment #18) > Eyal, et. al.: if you take the responsibility for your decision, There is no decision. There was just a rash commit before considering the need to bundle these fonts. But if it helps - I am willing to take full responsibility, such as it is, for a back-out. You can tell everyone that this calamity is all my fault :-P To be less facetious: It's a back-out. At any point one could argue for a commit of this bundling and, if that argument is convincing (not convincing me mind you, I have no authority in LO development) - it'll get bundled. > I don't agree with Eyal's naive perception that the project is overly bound > by "process" The perception is of the opposite... this commit was an example of poor process. (In reply to Heiko Tietze from comment #20) > New is not an immediate revert. In the context of this bug - why? > You and others raised good questions and the ticket is in NI state. And why isn't _that_ immediate revert? The good questions should be discussed before this is committed, not retroactively. As they had not been discussed beforehand, it is appropriate to back out, then have the discussion.
(In reply to Eyal Rozenberg from comment #21) > ... > > I don't agree with Eyal's naive perception that the project is overly bound > > by "process" > > The perception is of the opposite... this commit was an example of poor > process. > > (In reply to Heiko Tietze from comment #20) > > New is not an immediate revert. > > In the context of this bug - why? > > > You and others raised good questions and the ticket is in NI state. > > And why isn't _that_ immediate revert? > > The good questions should be discussed before this is committed, not > retroactively. As they had not been discussed beforehand, it is appropriate > to back out, then have the discussion. Sigh, as usual Eyal you've missed the point. I really would prefer not to expend the effort of cleaning up your messes, yet they keep coming... Here there is no imperative that the fonts contributed as part of the Google "DocRepair" project be removed. Community member Collabora either had a direct request for them or it was just a Dev's inkling to implement--end of story. End of "process". As that is the means by which the project is maintained, features are spawned, and dead/obsolete code is pruned. If you more directly want/need something--code it up and submit patches for peer review. Devs, aka Doers, decide. Then if there is a real reason to revert, ESC would provide such guidance--user issues and trustee concerns should not be beat to death in a BZ issue. Yet you do... Likewise, if for TDF concerns, the BoD takes up a sponsorship position of the FOSS Google DocRepair project--granting it could be a means to support hosting our own LibreOffice or Document Liberation font requirements (e.g. a home for OpenSymbol)--that discussion and any guidance would filter down through ESC, or be formally tendered by BoD.
(In reply to V Stuart Foote from comment #22) > Here there is no imperative that the fonts contributed as part of the Google > "DocRepair" project be removed. Community member Collabora either had a > direct request for them or it was just a Dev's inkling to implement--end of > story. End of "process". As that is the means by which the project is > maintained, features are spawned, and dead/obsolete code is pruned. > > If you more directly want/need something--code it up and submit patches for > peer review. Devs, aka Doers, decide. Then if there is a real reason to > revert, ESC would provide such guidance--user issues and trustee concerns > should not be beat to death in a BZ issue. Yet you do... > > Likewise, if for TDF concerns, the BoD takes up a sponsorship position of > the FOSS Google DocRepair project--granting it could be a means to support > hosting our own LibreOffice or Document Liberation font requirements (e.g. a > home for OpenSymbol)--that discussion and any guidance would filter down > through ESC, or be formally tendered by BoD. That's not accurate. Both TDF marketing and the design team want the fonts removed. Everyone involved knows or should know the discussions around dropping/replacing/adding fonts in the recent years. It's clear that this should have been a topic for ESC at the very least. I understand why such a process can slip from the mind when you are laser-focused on getting some cool thing done, I'm no stranger to it myself.
(In reply to V Stuart Foote from comment #22) > Sigh, as usual Eyal you've missed the point. I really would prefer not to > expend the effort of cleaning up your messes, yet they keep coming... Thank you for your kind words. That's very useful. > Here there is no imperative that the fonts contributed as part of the Google > "DocRepair" project be removed. Community member Collabora either had a > direct request for them or it was just a Dev's inkling to implement--end of > story. End of "process". And you believe this is ok? Suppose that the developer had an "inkling" to bundle not 7 fonts, but 70, or 700. Still ok? How about if they committed some bug in the app startup code that makes it crash. Still ok? > As that is the means by which the project is > maintained, features are spawned, and dead/obsolete code is pruned. So, you're saying nothing is ever reverted and no non-code is ever excised? > If you more directly want/need something--code it up and submit patches for > peer review. Devs, aka Doers, decide. Which is it? Peer review, or doers decide? If "doers decide" - what if a does make a mistake? If it's peer review - where was the review of this bundling? > Then if there is a real reason to > revert, ESC would provide such guidance--user issues and trustee concerns > should not be beat to death in a BZ issue. Yet you do... I shouldn't have even had to file this bug. It was just a rash commit which should have been backed out when people noticed it. The fact that it gets as far as a long discussion on Bugzilla is itself testament to a problem other than the (honest I believe) mistake.
(In reply to Eyal Rozenberg from comment #24) @Eyal, please refresh yourself with the meaning of "meritocracy"--especially in a FOSS project. Andras individually, and certainly Collabora have all the merit one could ask. What do you have but a loud persona? I'll grant that your RTL contributions to project have been merit worthy, but beyond that, hmm... Start actually contributing source (your input would be moderated there at least). Having *earned* sufficient merit, you might eventually be granted the ability to directly commit to LO core without review. That said the vast majority of commits have multiple eyes on them in addition to qa build testing--i.e. "peer review". There is no urgency to remove the DocRepair project fonts from core, immediately or in the future. I'm sure Collabora will let us know if it was a support request, and if Andras needed it for a project--that is fine--he has the merit to make that decision. Of course, trivial to migrate from core and rebundle as extension (embedded or hosted). ESC can address that in addition to any call to back out the fonts.
(In reply to V Stuart Foote from comment #25) > Andras individually, and certainly Collabora have all the merit one could > ask. ... What do you have but a loud persona? I'll grant that your RTL > contributions to project have been merit worthy, but beyond that, hmm... > ... Having *earned* sufficient merit, you might eventually be granted the > ability to directly commit to LO core without review. Surprising though it may seem to some, this bug is not about me. It's also not about the merit of Andras as a developer or Collabora as a company. It's about a commit which was made by mistake. > There is no urgency to remove the DocRepair project fonts from core, > immediately or in the future. So, you're not actually talking about urgency or lack thereof, you're just arguing that the commit should not be reversed and the fonts remain. Why? > I'm sure Collabora will let us know if it was > a support request, and if Andras needed it for a project--that is fine--he > has the merit to make that decision. I don't understand how that makes sense. If Andras needed a font for a project - he could download the font and use it in his project. If Collabora wants their users to have some collection of fonts - they can give their users a download link to those fonts or to a font installer. The question is whether these fonts need to be bundled and distributed with LibreOffice to all users. And so far there is no argument, AFAICT, for a "yes" answer.
(In reply to Eyal Rozenberg from comment #26) > ... It's about a commit which was made by mistake. Your opinion. Reality is that any commit has passed peer review and is *not* a mistake. If it causes a regression, then grounds for an urgent revert and the original Dev, or any other Dev with sufficient karma will back it out. Happens frequently! This is not that, and saying that it was "by mistake" is flat out rude. But that seems to be your shtick--loud, obnoxious and tone-deaf to nuance needed in FOSS.
(In reply to V Stuart Foote from comment #27) > Your opinion. Reality is that any commit has passed peer review and is *not* > a mistake. Ah, but that's the point. It's not my opinion. The committer reported the justification, which was a reliance on an unfounded assumption, and we have reasonably established that the assumption is invalid. And as for Caolan - he has told us right here that he doesn't know otherwise (and suggests building without these fonts by default). So we don't have anyone arguing that the commit is beneficial and thus justified. If that was actually being debated (e.g. "is appearance in 5% of documents in a corpus enough for us to bundle a metric equivalent?"), I wouldn't have filed this bug. Commits are not holy because they passed peer review; and mistakes happen. Why the insistence on eternalizing their effects?
[Automated Action] NeedInfo-To-Unconfirmed
The dev mailing list is probably a better place than a bugzilla issue for a general discussion as to whether we need processes to gatekeep what gets added by contributors either generally or just specifically for fonts. But on a few pieces: wrt 'This would not meaningfully help us with font replacement as MSO users do not get these fonts bundled with MSO', FWIW there is a "Cloud fonts list" section at https://support.microsoft.com/en-us/office/cloud-fonts-in-office-f7b009fe-037f-45ed-a556-b5fe6ede6adb which lists the fonts that are available to Microsoft 365 subscribers, and lists Agency FB, Baskerville Old Face, etc. There's also some related content at https://designtopresent.com/2024/06/20/a-guide-to-cloud-fonts-in-microsoft-office-365/ 'Is the "Google DocRepair project" an active effort we need to participate in?' I don't know of anything existing in LibreOffice that definitely fits there. There is the OpenSymbol font I suppose, but that's about it. I guess using that as a source to generate replacements for some Microsoft dingbat fonts is maybe plausible, but I don't think there was any serious effort to metrically match anything (except StarBats) when glyphs were added to OpenSymbol, but I don't know for sure. FWIW https://fonts.google.com/?query=The+DocRepair+Project is another useful link to see these fonts. 'if the clients of companies have signalled a need for replacement fonts or what other motivators there could be for shipping them.' The triggering sequence is more along the line of Collabora initially exploring what options exist for replacements of the relatively new contemporary MSOffice fonts and discovering that these other fonts exist along the way. Useful fonts to improve layout compatibility are a rare find, and to come across 7 all at once is exciting, even if they are not ultra-tier "pre selected as document default" fonts. 'we don't have anyone arguing that the commit is beneficial and thus justified' FWIW I think any fonts like these that help improve compatibility are a good thing. I have no numbers to indicate if it's a marginal improvement or a significant one but I think it is generally beneficial Anyhow, what I'll do is to merge https://gerrit.libreoffice.org/c/core/+/172337 to make bundling these docrepair fonts optional at build time, and default that to off. And we can make mention of it at the next ESC as to if that's the right default. (FWIW none of this typically affects the packages available through Linux distributions. which generally build --without-fonts to use the fonts packaged by the distro instead. So this affects what the standalone non-distro packages contain) If something like bug 159950 ever gets done then that's another future option of course, especially if we end up a a good place with hundreds of compatibility fonts. (On a technical note there, for the linux case we do have a certain ability to detect what fonts are missing from a document and request their installation from packagekit, but in practice we only do this for ultimate glyph fallback where there are no fonts available to render in a given language and just query for something that can render text in that language)
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd8ad433f04223193d270ba583ffa881984acf11 tdf#161941 add --with-docrepair-fonts option It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Caolán McNamara from comment #30) Thanks for a reply on the merits, Caolan... :-) > wrt 'This would not meaningfully help us with font replacement as MSO users > do not get these fonts bundled with MSO', FWIW there is a "Cloud fonts list" > section at > https://support.microsoft.com/en-us/office/cloud-fonts-in-office-f7b009fe- > 037f-45ed-a556-b5fe6ede6adb which lists the fonts that are available to > Microsoft 365 subscribers, and lists Agency FB, Baskerville Old Face, etc. Well, that's true, but let's not forget that list has 939 typeface variants from 409 distinct typefaces (counted with some regexp'ing and shell scripting). So I don't think that inclusion on that list is enough to merit bundling of a font file, let alone merely a metric equivalent. After all, Microsoft - which has no qualms about offering humongous installation files - have specifically decided _not_ to bundle such fonts. I'd even say they don't even merit committing into the source tree, but now it's a matter of how high the bar is set for committing into the tree vs having most users download the copy, which are two different arguments. The first one I will not press further, the second one will be settled with your commit. > If something like bug 159950 ever gets done then that's another future > option of course, especially if we end up a a good place with hundreds of > compatibility fonts. ... and another opportunity to drop these fonts from the LO sources. > (On a technical note there, Copying your technical note there.
Andras Timar committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/71f2a391237c1c770c6372a8d0e888b53f1d6777 Fix Repository.mk after 'add --with-docrepair-fonts option' (tdf#161941) It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.