Peter / All, sorry if I jumped in too soon (or the wrong place). I've added a link to the issues for ODF 1.4 here: https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.4+Changes
On 2026/06/19 04:50:15 [email protected] wrote: > I started to add a link for 1.4. So we can work on clustering the > entries for ODF 1.4 > > @Damjan: how did you cluster the ODF 1.3 issues? Did you wage them by > overall content or is there a field which helped? > > If anyone wants to help please join. It is really only reading the > document. You can ask question here. AI is able to help to answer your > questions too. > > Am 13.06.2026 um 08:13 schrieb [email protected]: > > > > Am 12.06.2026 um 06:58 schrieb Damjan Jovanovic: > >> 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. > > +1 > >> > >> 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. > > > > Renate has offered help to clarify if we have questions. > > > > We had an exchange discussion with Svante pre corona. (thanks to > > michael) I believe he is open if we have questions too. > > > > I am not sure, but I think Svante said that on OASIS level a test tool > > has been build. Maybe we can utilize that for testing. (if my memory > > does not betray me) > > > >> > >> Regards > >> Damjan > > > > All the best > > > > peter > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
