3 ms·
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
by 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.