You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2024/01/10 05:36:48 UTC
ODF 1.3 development
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
Re: ODF 1.3 development
Posted by Pedro Lino via dev <de...@openoffice.apache.org>.
Hi Damjan
Thank you for the update and for moving forward with this task!
It would be great to be able to use the same ODF version as other Office suites. I haven't found any issues moving back and forth but it always makes me wonder if I lost something when I see the message "This document uses an unsupported version of the Open Document Format"
For this feature only, I think it would be worth updating to 4.2!
Thank you!
All the best,
Pedro
> On 06/10/2026 6:30 PM WEST Damjan Jovanovic <da...@apache.org> wrote:
>
>
> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org> 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.
>
> And from what I see, there are even fewer changes from ODF 1.3 to 1.4, at
> least for formulas:
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#__RefHeading__1420416_253892949
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part4-formula/OpenDocument-v1.4-cs01-part4-formula.html#__RefHeading___Toc1134099_2705524876
>
> Regards
> Damjan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 & 1.4 development (was: ODF 1.3 development)
Posted by Dick Groskamp <di...@apache.org>.
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 Petko@apache.org 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 Petko@apache.org:
> >
> > Am 12.06.2026 um 06:58 schrieb Damjan Jovanovic:
> >> On Wed, Jun 10, 2026 at 10:07 PM <Pe...@apache.org> wrote:
> >>
> >>> Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic:
> >>>> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org>
> >>> 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: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
ODF 1.3 & 1.4 development (was: ODF 1.3 development)
Posted by Pe...@apache.org.
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 Petko@apache.org:
>
> Am 12.06.2026 um 06:58 schrieb Damjan Jovanovic:
>> On Wed, Jun 10, 2026 at 10:07 PM <Pe...@apache.org> wrote:
>>
>>> Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic:
>>>> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org>
>>> 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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Pe...@apache.org.
Am 12.06.2026 um 06:58 schrieb Damjan Jovanovic:
> On Wed, Jun 10, 2026 at 10:07 PM <Pe...@apache.org> wrote:
>
>> Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic:
>>> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org>
>> 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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Damjan Jovanovic <da...@apache.org>.
On Wed, Jun 10, 2026 at 10:07 PM <Pe...@apache.org> wrote:
>
> Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic:
> > On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org>
> 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
Re: ODF 1.3 development
Posted by Pe...@apache.org.
Am 10.06.2026 um 19:30 schrieb Damjan Jovanovic:
> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org> 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.
>
> And from what I see, there are even fewer changes from ODF 1.3 to 1.4, at
> least for formulas:
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#__RefHeading__1420416_253892949
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part4-formula/OpenDocument-v1.4-cs01-part4-formula.html#__RefHeading___Toc1134099_2705524876
>
> Regards
> Damjan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Jim Jagielski <ji...@jagunet.com>.
Great work.
> On Jun 10, 2026, at 1:30 PM, Damjan Jovanovic <da...@apache.org> wrote:
>
> On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org> wrote:
>
>> Hi
>>
>>
>> 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.
>
> And from what I see, there are even fewer changes from ODF 1.3 to 1.4, at
> least for formulas:
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#__RefHeading__1420416_253892949
> https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part4-formula/OpenDocument-v1.4-cs01-part4-formula.html#__RefHeading___Toc1134099_2705524876
>
> Regards
> Damjan
--
Jim
"This is an outrage!"
Tony Harrison
Re: ODF 1.3 development
Posted by Damjan Jovanovic <da...@apache.org>.
On Wed, Jan 10, 2024 at 7:36 AM Damjan Jovanovic <da...@apache.org> 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.
And from what I see, there are even fewer changes from ODF 1.3 to 1.4, at
least for formulas:
https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#__RefHeading__1420416_253892949
https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part4-formula/OpenDocument-v1.4-cs01-part4-formula.html#__RefHeading___Toc1134099_2705524876
Regards
Damjan
Re: ODF 1.3 development
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Marcus,
Am 12.01.24 um 20:23 schrieb Marcus:
> Am 12.01.24 um 19:19 schrieb Marcus:
>> Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
>>> [...]
>>>
>>> Can someone please create such a Wiki page, or give me access to do so?
>>>
>>> [...]
>>
>> that's a good idea. I'll create a new page in our Confluence Wiki.
>
> please have look here:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
That looks great!
Matthias
>
> You should have access to the page, so you can finish the first items
> yourself.
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: ODF 1.3 development
Posted by Marcus <ma...@wtnet.de>.
Am 14.01.24 um 18:44 schrieb Damjan Jovanovic:
> On Fri, Jan 12, 2024 at 7:23 PM Marcus <ma...@wtnet.de> wrote:
>> Am 12.01.24 um 19:19 schrieb Marcus:
>>> Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
>>>> [...]
>>>>
>>>> Can someone please create such a Wiki page, or give me access to do so?
>>>>
>>>> [...]
>>>
>>> that's a good idea. I'll create a new page in our Confluence Wiki.
>>
>> please have look here:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
>>
>> You should have access to the page, so you can finish the first items
>> yourself.
>>
> Thank you. I was hoping to use Mediawiki. I don't know why anyone uses
> Confluence. It's terrible, bloated, slow, expensive, messy, proprietary and
> closed source. The ASF is probably only getting it for free as a form of
> marketing.
I cannot see the most as disadvantages, especially together with JIRA
it's great - which we are not using.
> Anyway since so much was added to Confluence already, I've decided to
> continue there, and have added the part 2 and part 4 tasks as well now, and
> updated the items I already looked at.
I would like to move the other Wiki content into Confluence as
management is better there. However, it's may too much for my free time.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by "Keith N. McKenna" <ke...@comcast.net>.
Gavin McDonald wrote:
> Hi Keith,
>
> On Tue, Jan 16, 2024 at 5:32 PM Keith N. McKenna <ke...@comcast.net>
> wrote:
>
>> Marcus wrote:
>>> I would like to move the other Wiki content into Confluence as
>>> management is better there. However, it's may too much for my free time.
>>
>> Even if you could move it, the mwiki would need to stay active as it
>> does not appear that cwiki has a file upload to use it to distribute or
>> documentation.
>>
>
> Can I get an example of what you mean please Keith, so I can compare and at
> least
> take a look on the cwiki side.
>
> Thanks
>
> Gav...
>
>
>> Regards
>> Keith
>>
>>
>>
>
Gavin;
The mwiki has a file upload function that we use to upload PDF ODT files
of our uder guides. We then link those files to specific pages of the
wiki from which users can can download them.
For example for The Getting Started Guided we first upload the book file
to the wikiAnd then link to the Apache OpenOffice 4.1 User Guides (PDF)
page.
I hope this helps, if not let me know.
Regards
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Gavin McDonald <gm...@apache.org>.
Hi Keith,
On Tue, Jan 16, 2024 at 5:32 PM Keith N. McKenna <ke...@comcast.net>
wrote:
> Marcus wrote:
> > I would like to move the other Wiki content into Confluence as
> > management is better there. However, it's may too much for my free time.
>
> Even if you could move it, the mwiki would need to stay active as it
> does not appear that cwiki has a file upload to use it to distribute or
> documentation.
>
Can I get an example of what you mean please Keith, so I can compare and at
least
take a look on the cwiki side.
Thanks
Gav...
> Regards
> Keith
>
>
>
Re: ODF 1.3 development
Posted by Marcus <ma...@wtnet.de>.
Am 16.01.24 um 17:32 schrieb Keith N. McKenna:
> Marcus wrote:
>> I would like to move the other Wiki content into Confluence as
>> management is better there. However, it's may too much for my free time.
>
> Even if you could move it, the mwiki would need to stay active as it
> does not appear that cwiki has a file upload to use it to distribute or
> documentation.
sure, I don't meant to move everything, so that it is empty.
It's more the "normal" documentation on the pages itself. ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by "Keith N. McKenna" <ke...@comcast.net>.
Marcus wrote:
> I would like to move the other Wiki content into Confluence as
> management is better there. However, it's may too much for my free time.
Even if you could move it, the mwiki would need to stay active as it
does not appear that cwiki has a file upload to use it to distribute or
documentation.
Regards
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Damjan Jovanovic <da...@apache.org>.
On Fri, Jan 12, 2024 at 7:23 PM Marcus <ma...@wtnet.de> wrote:
> Am 12.01.24 um 19:19 schrieb Marcus:
> > Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
> >> [...]
> >>
> >> Can someone please create such a Wiki page, or give me access to do so?
> >>
> >> [...]
> >
> > that's a good idea. I'll create a new page in our Confluence Wiki.
>
> please have look here:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
>
> You should have access to the page, so you can finish the first items
> yourself.
>
>
Thank you. I was hoping to use Mediawiki. I don't know why anyone uses
Confluence. It's terrible, bloated, slow, expensive, messy, proprietary and
closed source. The ASF is probably only getting it for free as a form of
marketing.
Anyway since so much was added to Confluence already, I've decided to
continue there, and have added the part 2 and part 4 tasks as well now, and
updated the items I already looked at.
Thank you
Damjan
Re: ODF 1.3 development
Posted by Marcus <ma...@wtnet.de>.
Am 12.01.24 um 19:19 schrieb Marcus:
> Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
>> [...]
>>
>> Can someone please create such a Wiki page, or give me access to do so?
>>
>> [...]
>
> that's a good idea. I'll create a new page in our Confluence Wiki.
please have look here:
https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
You should have access to the page, so you can finish the first items
yourself.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Marcus <ma...@wtnet.de>.
Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
> [...]
>
> Can someone please create such a Wiki page, or give me access to do so?
>
> [...]
that's a good idea. I'll create a new page in our Confluence Wiki.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Regina Henschel <rb...@t-online.de>.
Hi,
Pedro Lino schrieb am 17.07.2024 um 13:13:
> Hi Bidouille
>
>> On 07/17/2024 7:32 AM WEST Bidouille <oo...@free.fr> wrote:
>
>> Microsoft seems to be engage to support ODF 1.4
>> https://forum.openoffice.org/en/forum/viewtopic.php?t=111685
>> Shouldn't we take the plunge and jump directly in 1.4?
>
> The short answer would be yes. But we need someone with the skills and the time to do it...
That is the key problem.
>
> Regarding the MS move, I find it odd that they are implementing a version that has not been released...
That is the Beta-version of MS Office. LibreOffice also supports
features of the upcoming ODF 1.4, only LibreOffice has not yet changed
the master branch to ODF 1.4.
>
> https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=4bf06d41-79ad-4c58-9e8e-018dc7d05da8
The current state of ODF 1.4 is on
https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4/csd01
ODF 1.3 is on
http://docs.oasis-open.org/office/OpenDocument/v1.3/
Kind regards,
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Pedro Lino <pe...@mailbox.org.INVALID>.
Hi Bidouille
> On 07/17/2024 7:32 AM WEST Bidouille <oo...@free.fr> wrote:
> Microsoft seems to be engage to support ODF 1.4
> https://forum.openoffice.org/en/forum/viewtopic.php?t=111685
> Shouldn't we take the plunge and jump directly in 1.4?
The short answer would be yes. But we need someone with the skills and the time to do it...
Regarding the MS move, I find it odd that they are implementing a version that has not been released...
https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=4bf06d41-79ad-4c58-9e8e-018dc7d05da8
https://opendocumentformat.org/
I hope it is not another "Embrace, extend, and extinguish" strategy for which MS is famous for...
In current versions they are making XML files incompatible with their own previous Office versions and seem to be discontinuing the binary formats (DOC, XLS, etc)
In the words of an old movie "In the end there can be only one!"
Regards,
Pedro
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: ODF 1.3 development
Posted by Damjan Jovanovic <da...@apache.org>.
On Wed, Jul 17, 2024 at 6:34 AM Bidouille <oo...@free.fr> wrote:
> Hello,
> Microsoft seems to be engage to support ODF 1.4
> https://forum.openoffice.org/en/forum/viewtopic.php?t=111685
> Shouldn't we take the plunge and jump directly in 1.4?
>
>
It doesn't really work like that. The changes are additive. The 1.4
documents will probably list changes from 1.3, so we first have to finish
1.3 to know what to change.
Only if 1.4 removes some ODF feature that 1.3 added, can work for us be
reduced. But that's extremely unlikely.
On the other hand, what we publicize to users is up to us. We could quietly
finish 1.3 and then proceed to develop 1.4, and only then publicize 1.4
support.
And why is Microsoft so eager to support ODF, before even LO?
Regards
Damjan
Re: ODF 1.3 development
Posted by Bidouille <oo...@free.fr>.
Hello,
Microsoft seems to be engage to support ODF 1.4
https://forum.openoffice.org/en/forum/viewtopic.php?t=111685
Shouldn't we take the plunge and jump directly in 1.4?
> ---snip---
>
> If others want to help, I'd rather push that branch upstream soon, so
> we can work on it together?
>
> Regards
> Damjan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org