Tor Lillqvist
80f8fe8479
This was much more complicated than expected. Most of that thanks to the inscrutability of fontconfig. Fonts from the Microsoft Store get installed in a separate folder per product, under the WindowsApps folder. Each such font product folder contains one or several TrueType font files, and metadata files, and preview images, etc. Add a C++ source file to fontconfig that uses DirectWrite to enumerate the available fonts. Take only those with a source type of DWRITE_FONT_SOURCE_TYPE_APPX_PACKAGE into account. Other fonts are found as before, looking in the system fonts folder (typically C:\Windows\Fonts) and in the per-user fonts folder (typically C:\Users\username\AppData\Local\Microsoft\Windows\Fonts). This C++ code requires headers from the winrt tree in the Windows SDK, so add that to SOLARINC. Sadly, thanks to the way fontconfig works (scanning directories for font files), I need to let it scan the folders of font products from the Microsoft Store to find the font files, even if the DirectWrite API would already give us the font file names directly. But I didn't want to modify fontconfig too much, so oh well. There was something weird in how fontconfig calculates the hash for directory names to be used in its cache files. It ended up creating more and more cache files for the same directories each time CODA-W was run. I could not understand what was going on, but in any case, just making sure that FcConfigMapFontPath() and FcConfigMapSalt() don't do anything on Windows seems to help. Also change the way freetype is built so that only the special FT_Done_MM_Var is exported, not all public functions. This was necessary because for some unknown reason, when linking the vcl DLL I started getting errors for the freetype symbols that happen to be linked into also the cairo DLL. If we eventually can switch to building all of core statically for CODA-W this problem will go away. Also stop defining FT_DEBUG_LOGGING, such logging will not show up anywhere for end-users, and fixing problems in freetype on Windows will have to be done by reproducing and debugging in the VS debugger anyway. There is still much to do to make fontconfig (and probably freetype and cairo) work really correctly on Windows. The most obvious thing is that the file name handling is broken. This is perhaps understandable as the port of that code to Windows is from over 20 years ago, I think. It works for file and folder names in ASCII, but most likely not for others. At least the user profile directory, under which per-user font files are stored, will definitely have non-ASCII in many cases. We should modify the code to use <tools/UnixWrappers.h>, so that all file system access is done using proper wide character (UTF-16) APIs. Pathnames that these libraries handle will then be in UTF-8. The opendir() etc emulation in fontconfig should also be replaced by adding such to UnixWrappers.h instead. Signed-off-by: Tor Lillqvist <tml@collabora.com> Change-Id: I4bc6e32dcc32ff74b79679edacee1aecebd774c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196336 Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com> Tested-by: Tor Lillqvist <tml@iki.fi> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197507 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@iki.fi>
LibreOffice
LibreOffice is an integrated office suite based on copyleft licenses and compatible with most document formats and standards. Libreoffice is backed by The Document Foundation, which represents a large independent community of enterprises, developers and other volunteers moved by the common goal of bringing to the market the best software for personal productivity. LibreOffice is open source, and free to download, use and distribute.
A quick overview of the LibreOffice code structure.
Overview
You can develop for LibreOffice in one of two ways, one recommended and one much less so. First the somewhat less recommended way: it is possible to use the SDK to develop an extension, for which you can read the API docs and Developers Guide. This re-uses the (extremely generic) UNO APIs that are also used by macro scripting in StarBasic.
The best way to add a generally useful feature to LibreOffice is to work on the code base however. Overall this way makes it easier to compile and build your code, it avoids any arbitrary limitations of our scripting APIs, and in general is far more simple and intuitive - if you are a reasonably able C++ programmer.
The Build Chain and Runtime Baselines
These are the current minimal operating system and compiler versions to run and compile LibreOffice, also used by the TDF builds:
- Windows:
- Runtime: Windows 10
- Build: wsl-as-helper + Visual Studio 2022
- macOS:
- Runtime: 11
- Build: 13 or later + Xcode 14.3 or later (using latest version available for a given version of macOS)
- Linux:
- Runtime: RHEL 9 or CentOS 9 and comparable
- Build: either GCC 12; or Clang 18 with libstdc++ 11
- iOS (only for LibreOfficeKit):
- Runtime: 14.5 (only support for newer i devices == 64 bit)
- Build: Xcode 12.5 and iPhone SDK 14.5
- Android:
- Build: NDK 27 and SDK 30.0.3
- Emscripten / WASM:
- Runtime: a browser with SharedMemory support (threads + atomics)
- Build: Qt 5.15 with Qt supported Emscripten 1.39.8
- See README.wasm
Java is required for building many parts of LibreOffice. In TDF Wiki article Development/Java, the exact modules that depend on Java are listed.
The baseline for Java is Java Development Kit (JDK) Version 17 or later.
The baseline for Python is version 3.11. It follows the version available in SUSE Linux Enterprise Desktop and the Maintenance Support version of Red Hat Enterprise Linux.
If you want to use Clang with the LibreOffice compiler plugins, the minimal version of Clang is 18. Since Xcode doesn't provide the compiler plugin headers, you have to compile your own Clang to use them on macOS.
You can find the TDF configure switches in the distro-configs/ directory.
To setup your initial build environment on Windows and macOS, we provide the LibreOffice Development Environment (LODE) scripts.
For more information see the build instructions for your platform in the TDF wiki.
The Important Bits of Code
Each module should have a README.md file inside it which has some
degree of documentation for that module; patches are most welcome to
improve those. We have those turned into a web page here:
However, there are two hundred modules, many of them of only peripheral interest for a specialist audience. So - where is the good stuff, the code that is most useful. Here is a quick overview of the most important ones:
| Module | Description |
|---|---|
| sal/ | this provides a simple System Abstraction Layer |
| tools/ | this provides basic internal types: Rectangle, Color etc. |
| vcl/ | this is the widget toolkit library and one rendering abstraction |
| framework/ | UNO framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from /uiconfig/ files |
| sfx2/ | legacy core framework used by Writer/Calc/Draw: document model / load/save / signals for actions etc. |
| svx/ | drawing model related helper code, including much of Draw/Impress |
Then applications
| Module | Description |
|---|---|
| desktop/ | this is where the main() for the application lives, init / bootstrap. the name dates back to an ancient StarOffice that also drew a desktop |
| sw/ | Writer |
| sc/ | Calc |
| sd/ | Draw / Impress |
There are several other libraries that are helpful from a graphical perspective:
| Module | Description |
|---|---|
| basegfx/ | algorithms and data-types for graphics as used in the canvas |
| canvas/ | new (UNO) canvas rendering model with various backends |
| cppcanvas/ | C++ helper classes for using the UNO canvas |
| drawinglayer/ | View code to render drawable objects and break them down into primitives we can render more easily. |
Rules for #include Directives (C/C++)
Use the "..." form if and only if the included file is found next to the
including file. Otherwise, use the <...> form. (For further details, see the
mail Re: C[++]: Normalizing include syntax ("" vs
<>).)
The UNO API include files should consistently use double quotes, for the benefit of external users of this API.
loplugin:includeform (compilerplugins/clang/includeform.cxx) enforces these rules.
Finding Out More
Beyond this, you can read the README.md files, send us patches, ask
on the mailing list libreoffice@lists.freedesktop.org (no subscription
required) or poke people on IRC #libreoffice-dev on irc.libera.chat -
we're a friendly and generally helpful mob. We know the code can be
hard to get into at first, and so there are no silly questions.
SAST Tools
PVS-Studio - static analyzer for C, C++, C#, and Java code.