OpenRTF icon indicating copy to clipboard operation
OpenRTF copied to clipboard

OpenRTF independent of OpenPDF?

Open andreasrosdal opened this issue 5 months ago • 3 comments

OpenRTF independent of OpenPDF, is this possible? To remove the OpenPDF dependency.

OpenRTF depends on RtfElementInterface from OpenPDF.

https://github.com/LibrePDF/OpenPDF/blob/master/openpdf-core/src/main/java/org/openpdf/text/RtfElementInterface.java

https://github.com/LibrePDF/OpenRTF/blob/master/src/main/java/com/lowagie/text/rtf/RtfBasicElement.java#L56

andreasrosdal avatar Aug 12 '25 06:08 andreasrosdal

In 2.0.0, the interface dependency is not there any more. Nevertheless, OpenRTF depends on types from OpenPDF. Was the interface the only problem and one can close this, or should it stay open? Maybe the proper way would be to extract the common types into a separate library that both OpenPDF and OpenRTF would use. Like that there would not be the direct dependency between them.

fridrich avatar Aug 18 '25 07:08 fridrich

The idea was that OpenPDF and OpenRTF be independent of each other. So no shared code or library. Then a few classes should be copied from OpenPDF to OpenRTF. I am not sure if this is really a very good idea, but it could be a good idea, if implemented properly. This would allow freedom for OpenPDF and OpenRTF to develop independently, which could allow each library to specialize and improve in their own directions.

andreasrosdal avatar Aug 18 '25 07:08 andreasrosdal

The problem with this kind of approach is that if there is a bug in one of the types, you will have to look around to fix it everywhere. In the times past, when I was still young, I collaborated on libwpd, libwpg and created libwps, libcdr, libvisio, libfreehand.... At a certain moment, we spun out the generic interfaces into librevenge and the conversion logic based on those interfaces into libodfgen and others. That proved itself with the time to be wonderful idea. Naturally, the interfaces had to be designed the way that adding elements to them was not breaking the class C++ ABI, but it was done by property lists. When adding some feature, one had to modify eventually the conversion logic if relevant, but the backward compatibility was maintained. From that time on, I am convinced about the common types. But then, I am not God the Father.

fridrich avatar Aug 18 '25 08:08 fridrich