If you copy contents from LibreOffice Writer to a plain text editor like gedit or Notepad, you will see that it does a straightforward thing: It copies the text and some basic formatting like converting bullets to ‘•’. For the Writer tables, the conversion is very simple right now: every cell is written in a separate line.

For example, if you have a table like this:

A | B
--|--
C | D

When you copy the table from LibreOffice Writer and paste it into a plain text editor, it will become something like this, which is not always desirable.

A
B
C
D

It is requested that like LibreOffice Calc, or Microsoft Word, and many other programs, the copy/paste mechanism should create a text like this:

A	B
C	D

The columns are separated by <tab>.

This feature request is filed in Bugzilla as tdf#144576:

• tdf#144576 – Copy a table from Writer to plain text editor or as un-formatted text pastes a list instead of matrix

Code pointers for Handling Writer tables

There are many steps in copy/pasting, including the data/format conversion and clipboard format handling. Here, you have to know that the document is converted to plain text via “text” filter.

The plaintext (ASCII) filter is located here in the LibreOffice core source code:

• sw/source/filter/ascii

Therefore, to change the copy/paste output, you have to fix the ASCII filter. That would also provide the benefit that plain text export will be also fixed as requested here.

In this folder, there are a few files:

$ ls sw/source/filter/ascii/
ascatr.cxx parasc.cxx wrtasc.cxx wrtasc.hxx

To change the output, you have to edit this file:

• sw/source/filter/ascii/wrtasc.cxx

In this file, there is a loop dedicated to create the output.

// Output all areas of the pam into the ASC file
do {
    bool bTstFly = true;
    ...
}

Inside this loop, the code iterates over the nodes inside the document structure, and extracts text from them. To check for yourself, add the one line below to the code, build LibreOffice, and then test. You will see that a * is appended before each node.

SwTextNode* pNd = m_pCurrentPam->GetPoint()->GetNode().GetTextNode();
if( pNd )
{
+   Strm().WriteUChar('*');
    ...
}

For example, having this table, with 1 blank paragraph up and down:

A | B
--|--
C | D

You will get this after copy/paste into a plain text editor:

*
*a
*b
*c
*d
*

To fix the bug, you have to differentiate between table cells and other nodes. Then, you should take care of the table columns and print tab between them.

To go further, you can only add star before table cells:

if( pNd )
{
    SwTableNode *pTableNd = pNd->FindTableNode();
+   if (pTableNd)
+   {
+       Strm().WriteUChar('*');
+    }
    ...
}

You can look into how other filters handled tables. For example, inside sw/source/filter/html/htmltab.cxx you will see how table is managed, first cell is tracked and appropriate functions to handle HTML table are called.

For the merged cells, the EasyHacker should first checks the behavior in …

When working with LibreOffice Impress, “Slide Master” is the place where you can change the templates used for different types of the slides used in your presentation. Here we discuss a possible improvement for the “Slide Master” by making the copy from master slides possible.

Copying the Master Page in Impress

To see the problem and the room for enhancement, open LibreOffice Impress, then choose “View->Master->Slide Master” from the menus. Then, try to copy the master page on the left in the slide sorter. Unfortunately, it is not possible.

Impress slide master

Having this feature is helpful, because different page types have many things in common, and being able to copy/paste helps creating templates much faster.

Impress Code Pointers

Looking into sd/source/core/drawdoc3.cxx, you can see a huge function SdDrawDocument::InsertBookmarkAsPage, which is relevant here. It contains ~600 lines of code. This huge function is in itself a problem. Therefore, to implement the enhancement, on should try to first refactor the function, then add a unit test in sd/qa/unit, find and then separate all the ~6 use cases, and fix the style/name merging.

After the cleanup, the main fix should be implemented. The suggested path to implement this comes from Jean-Francois. He suggest to improve the duplicate() method, which is described in the documentation:

• XDrawPageDuplicator interface, duplicate() method

As described in the above documentation, its role is to duplicate a page:

Creates a duplicate of a DrawPage or MasterPage, including the Shapes on that page and inserts it into the same model.

However, the implementation does not work for master slides, as the macros in the attachment file implies. The solution should add the needed implementation for master slides.

The implementation is inside sd/source/ui/unoidl/unomodel.cxx inside duplicate function:

// XDrawPageDuplicator
uno::Reference< drawing::XDrawPage > SAL_CALL SdXImpressDocument::duplicate( const uno::Reference< drawing::XDrawPage >& xPage )
{

...

}

Final Words

The above issue is filed as tdf#45617. If you like to work on it, just follow the Bugzilla link to see more information.

To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:

Getting Started (Video Tutorial)

In this blog post, I discuss gbuild for Java tests. The goal is to write a Makefile to compile and run a JUnit test for LibreOffice. You can also refer to part 1 and part 2 for a brif overiew on gbuild, the LibreOffice build system.

Macro Examples from gbuild for Java Tests

In the first post on gbuild, I have mentioned some macro examples including gb_Output_announce which was used to print nice messages like the ones including “[CXX]”. Now let’s explain some more macros related to Java tests.

Consider that you want to compile and run a JUnitTest. To do that, you need to write the test in a Java file, and create a Makefile to run that.

This is an example for running a test defined in Java file sw/qa/complex/indeterminateState/CheckIndeterminateState.java.

$(eval $(call gb_JunitTest_JunitTest,sw_complex))

$(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\
sw/qa/complex/indeterminateState/CheckIndeterminateState \
))

$(eval $(call gb_JunitTest_use_unoapi_jars,sw_complex))

$(eval $(call gb_JunitTest_add_classes,sw_complex,\
complex.indeterminateState.CheckIndeterminateState \
))

The make file for running this Java test consists of calling multiple macros. It starts with gb_JunitTest_JunitTest macro, which defines the test by its name, sw_complex. This macro is defined in solenv/gbuild/JunitTest.mk. If you grep for define in the same file, you will see this result:

$ grep -w define solenv/gbuild/JunitTest.mk
define gb_JunitTest_JunitTest
define gb_JunitTest_set_defs
define gb_JunitTest_add_classes
define gb_JunitTest_add_class
define gb_JunitTest_add_sourcefile
define gb_JunitTest_add_sourcefiles
define gb_JunitTest_use_jar
define gb_JunitTest_use_jars
define gb_JunitTest_use_jar_classset
define gb_JunitTest_add_classpath
define gb_JunitTest_use_system_jar
define gb_JunitTest_use_system_jars
define gb_JunitTest_use_external
define gb_JunitTest_use_externals
define gb_JunitTest_use_customtarget
define gb_JunitTest_use_customtargets
define gb_JunitTest_use_unoapi_jars
define gb_JunitTest_use_unoapi_test_class
define gb_JunitTest_set_unoapi_test_defaults
define gb_JunitTest_JunitTest

To stick to the macros used in the above example, I describe these macros:

gb_JunitTest_add_sourcefiles: This macro adds a Java source file to the test. It defines the code that adds the sw/qa/complex/indeterminateState/CheckIndeterminateState.java to the test. But please note that you should drop the .java extension:

$(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\
sw/qa/complex/indeterminateState/CheckIndeterminateState \
))

The other macro gb_JunitTest_use_unoapi_jars, adds the UNO API JAR files to be used with the test.

And in the end, you need to add the test class name using gb_JunitTest_add_classes macro. The class name is visible in the end.

The result can be quite complex, but it works.

java.exe -Xmx64M -classpath "$W/JavaClassSet/JunitTest/sw_complex;C:/cygwin64/home/user/lode/opt/share/java/junit.jar;$I/program;$W/Jar/OOoRunner.jar;$I/program/classes/libreoffice.jar;$W/Jar/test.jar" -Dorg.openoffice.test.arg.soffice="path:$I/program/soffice" -Dorg.openoffice.test.arg.env=PATH="$PATH" -Dorg.openoffice.test.arg.user=file:///$W/JunitTest/sw_complex/user org.junit.runner.JUnitCore complex.indeterminateState.CheckIndeterminateState

The above is the actual command that runs the test. Please note that if you forget the gb_JunitTest_add_classes macro to define the class name, the test may compile, but it will not run.

As an example, you can see the below patch. This patch fixes the problem of the JUnit test not running:

• Fix sw_complex JUnitTest not running

Final Words

Many macros are available in gbuild, making easier …

In the first blog post on LibreOffice build system, gbuild which uses GNU Make, I discussed some of the features of it. Here I discuss more about some gbuild tips and tricks that you may need.

Building a Single Module

In order to build a single module, you need to use its name. For example, to build only “odk”, which contains office development kit, you only have to type:

make odk

On the other hand, there are many other build targets associated with odk. By typing make odk, and then pressing tab, you will see this list, which shows possible targets:

odk odk.buildall odk.perfcheck odk.uicheck odk.all odk.check odk.screenshot odk.unitcheck odk.allbuild odk.checkall odk.showdeliverables odk.allcheck odk.clean odk.slowcheck odk.build odk.coverage odk.subsequentcheck

Each of the above is related to a specific task, in which many of them are common on different modules. Let’s discuss some of them:

make odk -> Builds odk module.

make odk.clean -> Cleans the odk module, removing the generated files.

make odk.check -> Runs test in odk module

make odk.uicheck -> It runs UI tests inside odk module

make odk.perfchek -> Runs performance/callgrind tests inside odk module

make odk.screenshot -> Creates screenshots inside odk module

To get a complete list and detailed description, run make help.

Handling Incomplete Builds

Sometimes because of OS crash or power outage, you may face problems when a build is stopped forcefully. In that case, you may see several zero byte object (*.o) files that exist, and prevent a successful build. In that case, you can find and remove them using this command:

$ rm `find -name *.o -size 0`

After that, you can retry your build without the above problem.

Customizing Build Configuration

The process of creating Makefile starts from configuring LibreOffice for build. This is done by invoking ./autogen.sh. The configuration parameters are read from autogen.input. The build configuration is done via configure.ac, which is an input for GNU autoconf.

There are various steps before the Makefiles are generated. For example, in order to make sure that a library is there when configuring the build, a very small C/C++ file is created, compiled and tested to ensure that the library is ready, and available to use with C/C++ code.

It is also possible to check for some specific version of library, and available functions. As an example, see this patch, which checks for specific version of ZXing library:

• tdf#153328 ZXing::ToSVG() Conditional usage

In the above example, multiple situations are handled:

1) When there is no ZXing library

2) When system ZXing library is used

And also, it is checked that specific version of ZXing is available:

1) When ZXing::ToSVG is not usable

2) When ZXing::ToSVG is usable

Then, the HAVE_ZXING_TOSVG symbolic constant is used in config_host/config_zxing.h.in, which can be used in C++ code.

Knowing More About gbuild

If you are interested in knowing more about …

Now that year 2024 has come, I want to briefly discuss the year 2023 around the development blog, and the outlook for 2024 here.

My goal is to help people understand LibreOffice code better, and ultimately get involved in LibreOffice core development to make LibreOffice better for everyone. In 2023, I wrote 23 posts around LibreOffice development in the dev blog (3 of them are unpublished drafts).

At The Document Foundation (TDF), our aim is to improve LibreOffice, the leading free/open source office software that you and many other people around the world use. Our work is community-driven, and we need your help.

LibreOffice conference 2023

Outlook For the New Year

My focus for 2024 in this blog will be:

1. Introducing new EasyHacks
2. Discussing how to fix crashes
3. Explaining LibreOffice architecture
4. Describing user interface creation with VCL
5. Explaining LibreOffice extensions

You can give feedback by writing a comment here, or sending an email to hossein AT libreoffice DOT org.

I provide mentoring support to those who want to start LibreOffice development. You are welcome to contact me if you need help to build LibreOffice and do some EasyHacks via the above email address.

I hope the best for you in the new year 2024.

In the previous part of the series on C/C++ strings, I described the string literal, plus how and why to use them. Then I introduced the new custom string literals and their benefits:

• String literals: C/C++ string data types part 2 – LibreOffice dev blog

Using the New Custom O[U]String Literals

In this post, I am going to discuss two EasyHacks dedicated to the use of the new O[U]String literals in the code.

• 158067 – Replace O(U)StringLiterals with custom O(U)String literals in code
• 158068 – Replace string literals with custom O(U)String literals in code

For tdf#158067, the idea is to use _oustr and _ostr suffixes instead of defining O[U]StringLiteral variables, and using them later.

For example,

OUString foo = "abc";

Becomes:

static constexpr OUStringLiteral FOO_STR = "abc";
...
OUString foo(FOO_STR);

The first line is using a compile time constant, but it is not clean, easy and not always desirable. After the introduction of the new shortcuts _ustr and _ostr, there is a new way to to create string literals in shorter form, available with C++20 standard. As C++20 is now the baseline for LibreOffice code, the new way is usable in the LibreOffice code.

For tdf#158068, the goal is to avoid C string literals, and replace those literals with the new O(U)String literals with appropriate prefixes. The benefit of doing that is to avoid run-time initialization of O[U]Strings, and do it in the compile time.

OUString foo("abc");

should become:

OUString foo(u"abc"_ustr);

Don’t Change Every O[U]String literal!

There are tests for O[U]StringLiterals that should not be touched at the moment. Eventually, developers will change them alongside the O[U]StringLiteral data types themselves.

In my previous blog post on creating LibreOffice extensions with Python, I have discussed how to write a Python code that works with LibreOffice API, and can be run and debugged in an IDE, and packed later in an extension. Now I discuss how to debug the Python code.

Here you can read the previous post:

• LibreOffice extensions with Python – part 1

Preparing the Debug Environment

First, you need the minimal extension, and the small Python script inside it. The complete extension as described in the previous post,  is available below, and the plan is to make it available among the other LibreOffice SDK examples:

https://gerrit.libreoffice.org/c/core/+/159938

For debugging, you can open the Python file main.py, and start editing it, adding the required functionalities.

To debug the Python program, the best way is to use an IDE with the LibreOffice internal Python as the interpreter. You only need to install LibreOffice, and LibreOffice SDK from libreoffice.org/download.

The LibreOffice internal Python interpreter resides in the program folder of the LibreOffice installation. The Python package for accessing UNO components is already installed.

In Linux, the default location of the interpreter is (for LibreOffice 7.6):

/opt/libreoffice7.6/program/python

In macOS, the default location is:

/Applications/LibreOffice.app/Contents/Resources/python

And on Windows, the default location is:

c:\Program Files\LibreOffice\program\python.exe

Configuring the Interpreter in an IDE

This is an example python configuration for PyCharm, a popular Python IDE.

Setting LibreOffice internal Python in PyCharm

With this configuration, you should be fine to start the debugging. By just clicking on the debug button, you can start running the script line by line, and use the debugging utilities in the IDE to check the value of the variables in order to be diagnose the possible problems.

As described in the previous part of the blog post, in the example Python code, the context is handled in different situations. Thus, you can use the same Python script and pack it as an extension.

Auto-Completion

Unfortunately, the autocomplete does not currently work for the methods that are available in the UNO components. This is because they are bridged dynamically, and thus autocomplete can not create the list of usable methods.

This can be improved with the use of Python auto-completion feature called REPL, and a utility package. Here I suggest using ptpython:

• ptpython- A better Python REPL

First, you need to install pip in LibreOffice internal python using PIP bootstrap, or ZazPip package. To do that, please refer to this question and answer on Ask LibreOffice:

• Install Python Package for LibreOffice

Then you should be able to use Python interactive console with auto-completion. To use it, you have to run this small code:

from ptpython.repl import embed
embed(globals(), locals())

This method works both on Windows and Linux, but not on APSO console. It is important to mention that this is not ideal as it only works in interactive console, and …

Ever wondered how to create a LibreOffice extension? Here I discuss how to do that via Python programming language. It is possible to run and debug the resulting Python code in an IDE, and then package the content as an extension.

LibreOffice Extensions with Python

If you have used LibreOffice extensions, you know that many exciting things can be done with extensions. Extensions can open LibreOffice applications, create new documents, read and write text and images inside the documents, and convert them to all possible formats. They can have their own menus and toolbar buttons, and have nice looking GUIs to interact with the users.

To write an extension, the easiest way is to use LibreOffice BASIC language. You can refer to this tutorial for such an approach here:

• TDF Wiki – Create a Hello World LibreOffice extension

But with Python, you will have access to a big set of packages, that is one of the many strengths of the Python programming language. You can do almost anything possible with a software with those packages. Furthermore, LibreOffice has its own Python interpreter! In this way, installing and using a Python extension would be much easier.

Handling Context in LibreOffice Extensions

First of all, you should know about context, and you should be able to have that variable to be able to use LibreOffice API.

There can be at least 3 different possibilities for running a Python program with LibreOffice:

1. Running the Python program with APSO inside LibreOffice
2. Running the Python program as an extension inside LibreOffice
3. Running the Python program as a process outside LibreOffice

In each of these possibilities, the way to get the context and use them is different.

Structure of a LibreOffice Extension

Extensions are essentially zip files that have specific files known to LibreOffice inside them. This is the structure of a Python extension:

• META-INF/ : required folder
  META-INF/manifest.xml: Specification of the script(s), menu/toolbar and language files
• pkg-description/ : required folder
  pkg-description/pkg-description.en: Description of the extension in text, which can be also in languages other than English
• registration/: required folder
  registration/license.txt: License of the extension

• description.xml: Description of the extension in XML format, as displayed in the extension manager
• main.py: The main script. Then name can be anything but it should
  be specified in the META-INF/manifest.xml

Contents of the Files

Most of the contents of the files are re-usable, so you can use the skeleton extension, and build your extension around that. But, the Python script is important and we will talk about it here.

From the above 3 possible situations for LibreOffice, in order to be able to use the code as extension, you should add these this 2 lines should be in the Python file

g_ImplementationHelper = unohelper.ImplementationHelper()
g_ImplementationHelper.addImplementation(MainJob,
"org.extension.sample.do",("com.sun.star.task.Job",), )

In addition, this import is also required:

from com.sun.star.task import XJobExecutor

Then, a Python class with this definition is needed:

class MainJob …

In the first part of the series on string types in LibreOffice, I discussed some of the string data types that are in use in various places of the LibreOffice code. I discussed various character and string data types briefly: OString, OUString, char/char*, sal_Unicode, sal_Unicode*, rtl_String, rtl_uString and also std::string. Now I want to explain string literals.

String Literals

In C/C++, a string literal is a sequence of characters in double quotations, and represent read-only textual data. For example:

const char *str = "abc";

Please note that it is different from a character literal, which is a single character in single quotation marks:

const char c = 'a';

The non read-only version of these data types does not have const in it.

The char* data type is widely used in C programming language, but it is not the data type of choice in LibreOffice. As described in my previous post, OString is used for for 8-byte text, and OUStringis used for Unicode text in LibreOffice. It is worth noting that it is possible to store UTF-8 encoded Unicode text in OString.

In the past, it was possible to convert the const char* literal to OString/OUString like this: (it will not compile now)

OString sText = "abc";
OUString sUniText = u"abc";

It was not an efficient way to define and use such strings. A read-only memory is used to store the plain string literals. But then, a new dynamic memory chunk is allocated on the heap to store the new O[U]String object, and through the constructor, that read-only memory is copied into that memory. Also, the new OUString needs reference counting. These are non-necessary expensive operations, and we should avoid them.

O[U]StringLiteral

In LibreOffice, OStringLiteral and OUStringLiteral are the data types used to represent string literals for ASCII and Unicode data, respectively.

As an example, you can see lines like this in LibreOffice .cxx files:

static constexpr OUStringLiteral sStart = u"ABC";
static constexpr OStringLiteral sEnd("DEF");

The constexpr ensures that the expression is evaluated at compiled time, and this can improve the performance of the program. Also, avoiding reference counting in O[U]String helps to make the operation cheaper.

Later, OString/OUString variables are constructed from the OUStringLiterals. Or, they are passed to functions that expect OString/OUString parameters. The difference is that when static constexpr literals are used, the memory used for storing data is not the dynamic memory, it is allocated once, and it is read-only, which increases the performance. This approach is only usable when you work with strings that will be only initialized once, and will not be manipulated later.

String Literals in Headers

If you are working with a .hxx C++ header file, you have to use inline keyword to avoid creating duplicate copies of the global variable. For example:

inline constexpr OUStringLiteral ABC(u"abc");

Later we will see that we can re-write the above with a suffix as:

inline constexpr OUString ABC = u"abc"_ustr;

Essentially …