3 ms·

> I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it I've lost this optimism a long time ago when I realized how much deni

> I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it I've lost this optimism a long time ago when I realized how much denialism and how little actual factual, detailed knowledge there is among vocal proponents for Linux and free software. For example, the entire font handling stack on Linux is a hot seething mess of horrible dysfunctionality, wrongly implemented and starting out from the wrong principles (IMHO), yet nobody is working to improve it because everyone keeps telling you it's a solved problem. More specifically, years ago ago I hacked together solutions to script LibreOffice from the 'outside' as it were because its macro system is such an utter painful failure in so many ways. Not only was a single website written in Japanese the only source for a reasonable rundown of LibreOffice's API, it also introduced me, indirectly, to the fact that the people who initially wrote OpenOffice were apparently not comfortable with Java being a strictly OOP language, so they did their best to write code that to a degree circumvents that, leading to a terrifyingly bad user experience and a hint of the convoluted horrors that might lurk in the source code. The glacial pace of LibreOffice's development where the appearance of the tiniest of innovations leads, every few years, to great public announcements and a new version number, has convinced me that the community has painted themselves in a corner with an unmanageable code base and devs that are, likely, in complete denial that the only way out would be a complete rewrite of the software, something that is, understandably, too hard to stomach.

chris_wot 2y ago
I challenge you on each of these points: You make a big claim that font handling is a “hot seething mess”, but you do t explain why. Harfbuzz and ICU are hardly what you describe. LibreOffice’s API is extensively documented: * https://api.libreoffice.org/ https://api.libreoffice.org/ * the Developers Guide has been around for literally over a decade and is now located at https://wiki.documentfoundation.org/Documentation/DevGuide https://wiki.documentfoundation.org/Documentation/DevGuide LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation. LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly. I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings. I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.
- DemocracyFTW2 2y ago
  Sorry it took some time before I could come back to this. When I said font handling, I should've really said fontconfig. FWIW, https://eev.ee/blog/2015/05/20/i-stared-into-the-fontconfig-and-the-fontconfig-stared-back-at-me/ https://eev.ee/blog/2015/05/20/i-stared-into-the-fontconfig-... delivers a pretty good rundown of why fontconfig is problematic, and also correctly states that "the documentation is atrocious". It's simply a piece of software that attempts to do too much while having an insufficient understanding of the problem. One of fontconfig's foundational problems is that it gets priorities wrong: when you have a series of configuration files, which ones should prevail in case of conflict, the global ones or the local ones? fontconfig thinks it should be the global ones, meaning whatever you configure you have to specifically override another rule. Also, for all its complexity that tries to deal with font names, file names, languages, and font styles, fontconfig omits the one obvious entity that is crucial for font rendering, the Unicode codepoint. In short, CSS got it right: in CSS, you can define a `@font.face` that is composed of various code point ranges that are associated with font resources. This allows fine control over each displayed character. In contrast, fontconfig only lets you configure preferences of one font over the other where your second choice only comes to bear when your first font is indeed missing a given code point. And that is really all that it does; its complexity is just fluff, imagined functionality that isn't usable. A remark is in place: first, it's ten plus years ago that I dealt with this stuff and tried to hack LibreOffice, so things might have changed. Also, I have to pull all of this from memory. Second, not all of Linux font rendering is a mess (HarfBuzz for one thing is great), but, specifically and crucially, fontconfig is, and its documentation at http://www.freedesktop.org/software/fontconfig/fontconfig-user.html http://www.freedesktop.org/software/fontconfig/fontconfig-us... has not changed a bit since then. As for Libre/OpenOffice, the only documentation site that goes into details of the API is still up and has been last updated in 2023, so kudos for that. It's at https://openoffice3.web.fc2.com https://openoffice3.web.fc2.com and in Japanese language; I did extensive searches back in the day and am sure this is the best I could find. Also I must add that for whatever reason I targeted Apache OpenOffice in the day, not LibreOffice, so that's one more thing that could conceivably make a difference here. Here's the Hello World JavaScript example from the documentation: importClass(Packages.com.sun.star.uno.UnoRuntime) importClass(Packages.com.sun.star.text.XTextDocument) importClass(Packages.com.sun.star.text.XText) importClass(Packages.com.sun.star.text.XTextRange) importClass(Packages.com.sun.star.beans.XPropertySet) importClass(Packages.com.sun.star.awt.FontSlant) importClass(Packages.com.sun.star.awt.FontUnderline) oDoc = XSCRIPTCONTEXT.getDocument() xTextDoc = UnoRuntime.queryInterface(XTextDocument,oDoc) xText = xTextDoc.getText() xTextRange = xText.getEnd() pv = UnoRuntime.queryInterface(XPropertySet, xTextRange) pv.setPropertyValue( "CharHeight", 16.0 ) // Double pv.setPropertyValue( "CharBackColor", new java.lang.Integer(1234567) ) pv.setPropertyValue( "CharUnderline", new java.lang.Short(Packages.com.sun.star.awt.FontUnderline.WAVE) ) pv.setPropertyValue( "CharPosture", Packages.com.sun.star.awt.FontSlant.ITALIC ) xTextRange.setString( "Hello World (in JavaScript)" ) So when I say that the API is convoluted and squirts Java OOP, I specifically mean the way you have to use `XSCRIPTCONTEXT` and `UnoRuntime.queryInterface()`. One might think this is caused by the use of a scripting language instead of OpenOffice's 'native' Java, but no: import com.sun.star.uno.UnoRuntime; import com.sun.star.frame.XModel; import com.sun.star.text.XTextDocument; import com.sun.star.text.XTextRange; import com.sun.star.text.XText; import com.sun.star.script.provider.XScriptContext; public class HelloWorld { public static void printHW(XScriptContext xScriptContext) { XModel xDocModel = xScriptContext.getDocument(); // getting the text document object XTextDocument xtextdocument = (XTextDocument) UnoRuntime.queryInterface( XTextDocument.class, xDocModel); XText xText = xtextdocument.getText(); XTextRange xTextRange = xText.getEnd(); xTextRange.setString( "Hello World (in Java)" ); } } All of this is completely superfluous. Why would you call a method and pass it the `class` attribute of a class (?) and a 'model' (?) of the current document and then cast the return document so it obtains / becomes an instance of that class? Again, that line is literally, after renaming Foo foo = (Foo) UnoRuntime.queryInterface( Foo.class, FOO ); If that doesn't look contorted to you, I don't know what will. When you say "LibreOffice is not based on Java" I will not challenge you on that but just say that back in the day when I tried to 'remotely control' LibreOffice from a scripting language all I got to see was a Java API, whatever it was bolted onto didn't matter, like at all. Likewise, I will not dispute different evaluations of development speed or whether a rewrite would be a good thing since those points are probably too subjective.

chris_wot 2y ago

I challenge you on each of these points: You make a big claim that font handling is a “hot seething mess”, but you do t explain why. Harfbuzz and ICU are hardly what you describe. LibreOffice’s API is extensively documented: * https://api.libreoffice.org/ https://api.libreoffice.org/ * the Developers Guide has been around for literally over a decade and is now located at https://wiki.documentfoundation.org/Documentation/DevGuide https://wiki.documentfoundation.org/Documentation/DevGuide LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation. LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly. I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings. I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.

DemocracyFTW2 2y ago
Sorry it took some time before I could come back to this. When I said font handling, I should've really said fontconfig. FWIW, https://eev.ee/blog/2015/05/20/i-stared-into-the-fontconfig-and-the-fontconfig-stared-back-at-me/ https://eev.ee/blog/2015/05/20/i-stared-into-the-fontconfig-... delivers a pretty good rundown of why fontconfig is problematic, and also correctly states that "the documentation is atrocious". It's simply a piece of software that attempts to do too much while having an insufficient understanding of the problem. One of fontconfig's foundational problems is that it gets priorities wrong: when you have a series of configuration files, which ones should prevail in case of conflict, the global ones or the local ones? fontconfig thinks it should be the global ones, meaning whatever you configure you have to specifically override another rule. Also, for all its complexity that tries to deal with font names, file names, languages, and font styles, fontconfig omits the one obvious entity that is crucial for font rendering, the Unicode codepoint. In short, CSS got it right: in CSS, you can define a `@font.face` that is composed of various code point ranges that are associated with font resources. This allows fine control over each displayed character. In contrast, fontconfig only lets you configure preferences of one font over the other where your second choice only comes to bear when your first font is indeed missing a given code point. And that is really all that it does; its complexity is just fluff, imagined functionality that isn't usable. A remark is in place: first, it's ten plus years ago that I dealt with this stuff and tried to hack LibreOffice, so things might have changed. Also, I have to pull all of this from memory. Second, not all of Linux font rendering is a mess (HarfBuzz for one thing is great), but, specifically and crucially, fontconfig is, and its documentation at http://www.freedesktop.org/software/fontconfig/fontconfig-user.html http://www.freedesktop.org/software/fontconfig/fontconfig-us... has not changed a bit since then. As for Libre/OpenOffice, the only documentation site that goes into details of the API is still up and has been last updated in 2023, so kudos for that. It's at https://openoffice3.web.fc2.com https://openoffice3.web.fc2.com and in Japanese language; I did extensive searches back in the day and am sure this is the best I could find. Also I must add that for whatever reason I targeted Apache OpenOffice in the day, not LibreOffice, so that's one more thing that could conceivably make a difference here. Here's the Hello World JavaScript example from the documentation: importClass(Packages.com.sun.star.uno.UnoRuntime) importClass(Packages.com.sun.star.text.XTextDocument) importClass(Packages.com.sun.star.text.XText) importClass(Packages.com.sun.star.text.XTextRange) importClass(Packages.com.sun.star.beans.XPropertySet) importClass(Packages.com.sun.star.awt.FontSlant) importClass(Packages.com.sun.star.awt.FontUnderline) oDoc = XSCRIPTCONTEXT.getDocument() xTextDoc = UnoRuntime.queryInterface(XTextDocument,oDoc) xText = xTextDoc.getText() xTextRange = xText.getEnd() pv = UnoRuntime.queryInterface(XPropertySet, xTextRange) pv.setPropertyValue( "CharHeight", 16.0 ) // Double pv.setPropertyValue( "CharBackColor", new java.lang.Integer(1234567) ) pv.setPropertyValue( "CharUnderline", new java.lang.Short(Packages.com.sun.star.awt.FontUnderline.WAVE) ) pv.setPropertyValue( "CharPosture", Packages.com.sun.star.awt.FontSlant.ITALIC ) xTextRange.setString( "Hello World (in JavaScript)" ) So when I say that the API is convoluted and squirts Java OOP, I specifically mean the way you have to use `XSCRIPTCONTEXT` and `UnoRuntime.queryInterface()`. One might think this is caused by the use of a scripting language instead of OpenOffice's 'native' Java, but no: import com.sun.star.uno.UnoRuntime; import com.sun.star.frame.XModel; import com.sun.star.text.XTextDocument; import com.sun.star.text.XTextRange; import com.sun.star.text.XText; import com.sun.star.script.provider.XScriptContext; public class HelloWorld { public static void printHW(XScriptContext xScriptContext) { XModel xDocModel = xScriptContext.getDocument(); // getting the text document object XTextDocument xtextdocument = (XTextDocument) UnoRuntime.queryInterface( XTextDocument.class, xDocModel); XText xText = xtextdocument.getText(); XTextRange xTextRange = xText.getEnd(); xTextRange.setString( "Hello World (in Java)" ); } } All of this is completely superfluous. Why would you call a method and pass it the `class` attribute of a class (?) and a 'model' (?) of the current document and then cast the return document so it obtains / becomes an instance of that class? Again, that line is literally, after renaming Foo foo = (Foo) UnoRuntime.queryInterface( Foo.class, FOO ); If that doesn't look contorted to you, I don't know what will. When you say "LibreOffice is not based on Java" I will not challenge you on that but just say that back in the day when I tried to 'remotely control' LibreOffice from a scripting language all I got to see was a Java API, whatever it was bolted onto didn't matter, like at all. Likewise, I will not dispute different evaluations of development speed or whether a rewrite would be a good thing since those points are probably too subjective.