On Wed, Jun 10, 2026 at 10:07 PM <[email protected]> wrote: > > Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic: > > On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <[email protected]> > wrote: > > > >> Hi > >> > >> I've started looking at how to add ODF 1.3 support to OpenOffice. > >> > >> If you scroll to the end of the monstrously long part 3 of the ODF 1.3 > >> specification at > >> > https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html > >> where you'll see "Appendix G: Changes From ODF 1.2 (Non Normative)". > >> Then examine: > >> > >> "Document Fields – General 7.3.1 Office-3783" > >> > >> and you follow that link to "Office-3783" and have a read, you'll see > that > >> all it does is *fix a typo*: > >> Section 7.3.1 used to contain "OpenDocument fields display information > >> about the current document or about a specific part of the current > >> document.," - note the superfluous comma at the end - and now ends > >> without that comma! > >> > >> So that item can immediately be ticked off as completed, because there > is > >> nothing we have to do. > >> > >> The same is also true for at least: > >> "table:table-background 19.733 Office-3954" > >> > >> And: > >> "Normative References 1.3 Office-3868" > >> updates the <manifest:media-type> tag to refer to RFC6838 instead of the > >> older RFC4288, which also might require no work to implement. > >> > >> So what we need is a table in our Wiki, with all "Changes From ODF 1.2" > >> items from all the 1.3 documents (there's several), and then to read > over > >> them and mark off the ones that are irrelevant or complete, and track > >> progress on the other items where we do have some development to do on > our > >> side. > >> > >> Can someone please create such a Wiki page, or give me access to do so? > >> > >> And out of interest, how do you find how and where we use an XML element > >> or attribute? For example let's examine: > >> <draw:applet> 10.4.7 Office-2044 > >> which is deprecated by ODF 1.3. > >> First remember our XML parsing doesn't work on strings, that would be > too > >> slow. Rather strings are converted to unique integers, and then we do > fast > >> integer comparisons. > >> So if you go to main/xmloff and "grep applet * -R" you'll see: > >> source/core/xmltoken.cxx: TOKEN( "applet", > >> XML_APPLET ), > >> where XML_APPLET is an integer constant (from an enum) that the "applet" > >> element will be converted to. > >> Then go to OpenGrok and do a "Full Search" for "XML_APPLET", and you can > >> see where that's used. > >> > >> I've also created a local odf-1.3 Git branch for any development, but at > >> present it only has 1 small patch to stop the version upgrade warning: > >> > >> ---snip--- > >> diff --git a/main/sfx2/source/doc/objstor.cxx > >> b/main/sfx2/source/doc/objstor.cxx > >> index d794747b60..89ab8e1ca3 100644 > >> --- a/main/sfx2/source/doc/objstor.cxx > >> +++ b/main/sfx2/source/doc/objstor.cxx > >> @@ -856,8 +856,8 @@ sal_Bool SfxObjectShell::DoLoad( SfxMedium *pMed ) > >> if ( sVersion.getLength() ) > >> { > >> double nVersion = sVersion.toDouble(); > >> - if ( nVersion > 1.20001 && > >> SfxObjectShell_Impl::NeedsOfficeUpdateDialog() ) > >> - // ODF version greater than 1.2 - added some > >> decimal places to be safe against floating point conversion errors > (hack) > >> + if ( nVersion > 1.30001 && > >> SfxObjectShell_Impl::NeedsOfficeUpdateDialog() ) > >> + // ODF version greater than 1.3 - added some > >> decimal places to be safe against floating point conversion errors > (hack) > >> { > >> ::rtl::OUString sDocumentURL( > >> pMedium->GetOrigURL() ); > >> ::rtl::OUString aSystemFileURL; > >> ---snip--- > >> > >> If others want to help, I'd rather push that branch upstream soon, so we > >> can work on it together? > >> > >> Regards > >> Damjan > >> > >> > > I've now closed a total of 64 of the 190 ODF 1.3 changes (33.68%) on > > https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes. > > > > It was mostly done by finding the ones that were documentation fixes > (typos > > and description improvements), or that we currently already implement, > and > > closing them off without any code changes. This is easy and doesn't > require > > much knowledge or technical skill, so please join in if you can. > i join the effort. I try to add comment if we have a gap. >
Thank you so much. With Peter's help, we are now at 43.68% completion :-). I was also thinking that since we want to support both ODF 1.3 and 1.4, there might be a way to develop them both faster. If we focus only on ODF 1.3, and ignore 1.4, then by the time we finish 1.3 we will have forgotten a lot of the code changes, and developing 1.4 will require more time. But we could also divide up the total work by feature category, and do what is effectively a depth-first traversal, developing each feature category for both versions together before moving onto the next feature category. For example ODF 1.3 has changes to the "number" namespace: we need to implement number:fill-character, number:forced-exponent-sign, number:min-decimal-places, etc., and ODF 1.4 also has changes to the "number" namespace: number:calendar, number:num-list-format, and number:num-list-label. If someone starts developing number changes for ODF 1.3, then jumps to 1.3 formula development, 1.3 chart changes, 1.3 style changes, etc., then by the time 1.3 is finished, they would have forgotten a lot about numbers, and developing 1.4 number changes will be more difficult and take longer. But developing all the number changes for both 1.3 and 1.4 at the same time, before moving onto another topic, allows them to specialize in numbers, go deeper into numbers, understand them more, and will probably increase development efficiency, decrease bugs, and may even discover and fix other bugs. We are late to ODF 1.3/1.4 development, but that also lets us benefit from second-mover advantages, including the existence of many ODF 1.3/1.4 implementations we can test against, and a better view of the whole landscape which lets us decrease development effort. Regards Damjan
