OOo Status digest Volume 2, issue #3- January 21st 2008

[Hubert Figuiere-4]

This is the weekly status digest of what the Novell
OpenOffice team is up to. It will relate changes made to OpenOffice
(ooo-build or upstream) and list important work in progress.

Highlights for the weeks from January 14th to January 20th 2008.

- Impress fix for #i59061: move up and down in outline. In ooo-build
and a CWS (hub)
- VBA: fix for #n353248 (Application.Assistant was not supported) in
ooo-build (Jianhua)
- Calc: fixed a large issue with autofilter (kohei)
- VBA/Calc: fix for #n353687 name of autoshape was not imported (npower)
- Fix n#35447 / i#85336: the system file dialog did not have shortcuts
while the OOo one does (hub)


In progress:

- Enhanced fields support (florian)
- OpenXML import / export in the xmlfilter03 (sun + fridrich, kohei and
hub)
- More VBA: npower9 for dialog rework, npower10 for other basic
issues and npower11 for API related changes.
- More CJK support
- New GUI layout code with JanN.



_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

> - OpenXML import / export in the xmlfilter03 (sun + fridrich, kohei and
> hub)
>  
Hi,

I tried out OdfConverter 1.1.7, and it converts docx formatting nicely
to ODF (though a bit slow).   I have a few questions if that's OK.  :)
1. Is this the same technology that will be in the upstream
OpenOffice.org 3.0.0?
2. OdfConverter converter uses a a separate binary, but Go-OO
OpenOffice.org 2.3.0 seems to have it integrated.  I assume OdfConverter
will be integrated into the upstream OOo 3.0.0?
3. The add-in for Microsoft Office uses the same code to do the same in
reverse, correct?   To save in .odt, MSO creates a .docx as a temporary
file, then calls the binary to convert to .odt?
4. The credit above mentions Sun, but I don't see Sun mentioned here <
http://odf-converter.sourceforge.net/>.   Is all the OpenOffice.org
development for OdfConverter, including Sun's work,  going back into the
SF.net project?
5. The OdfConverter version from Sourceforge requires .Net framework
2.0, but the version from download.go-oo.org seems not to.   Is .Net  
just for MSO integration?


Andrew
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Hubert Figuiere-4]

On Tue, 2008-01-22 at 07:28 -0700, Andrew Ziem wrote:
> > - OpenXML import / export in the xmlfilter03 (sun + fridrich, kohei and
> > hub)
> >

This is not the ODF converter... This is the OpenXML filter that is done
upstream.

>  
> Hi,
>
> I tried out OdfConverter 1.1.7, and it converts docx formatting nicely
> to ODF (though a bit slow).   I have a few questions if that's OK.  :)
> 1. Is this the same technology that will be in the upstream
> OpenOffice.org 3.0.0?

See above.

> 2. OdfConverter converter uses a a separate binary, but Go-OO
> OpenOffice.org 2.3.0 seems to have it integrated.  I assume OdfConverter
> will be integrated into the upstream OOo 3.0.0?

OdfConvert won't be integrated upstream. See above.

> 3. The add-in for Microsoft Office uses the same code to do the same in
> reverse, correct?   To save in .odt, MSO creates a .docx as a temporary
> file, then calls the binary to convert to .odt?
> 4. The credit above mentions Sun, but I don't see Sun mentioned here <
> http://odf-converter.sourceforge.net/>.   Is all the OpenOffice.org
> development for OdfConverter, including Sun's work,  going back into the
> SF.net project?
> 5. The OdfConverter version from Sourceforge requires .Net framework
> 2.0, but the version from download.go-oo.org seems not to.   Is .Net  
> just for MSO integration?

I think I just answered these.


Hub

_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

Hubert Figuiere wrote:

> On Tue, 2008-01-22 at 07:28 -0700, Andrew Ziem wrote:
>  
>>> - OpenXML import / export in the xmlfilter03 (sun + fridrich, kohei and
>>> hub)
>>>
>>>      
>
> This is not the ODF converter... This is the OpenXML filter that is done
> upstream.
>  

Thanks for the answer.  So, once the OpenXML filter is integrated into
OOo 3.0.0 mainstream, will the OpenOffice.org integration for
OdfConverter become obsolete?


Andrew
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Hubert Figuiere-4]

On Tue, 2008-01-22 at 07:40 -0700, Andrew Ziem wrote:
> Thanks for the answer.  So, once the OpenXML filter is integrated
> into
> OOo 3.0.0 mainstream, will the OpenOffice.org integration for
> OdfConverter become obsolete?

OdfConverter is an interim solution. We are confident that the OOX
importer is already better or that it will be pretty soon (xmlfilter02
has been merged in m243, which mean that it is already in the mainline,
albeit disabled), and that it is faster.

For the export nothing has been started yet.


Hub

_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Tor Lillqvist-3]

> will the OpenOffice.org integration for OdfConverter become obsolete?

Well, the odf-converter (as the preferred spelling/casing is, I think) "integration" into OpenOffice.org is rather loose anyway. There is a patch in ooo-build that enables filters to run a separate preprocessing (when lolading) and postprocessing (when saving) program. When loading and saving OOXML formats this pre/postprocessing is used, and the program in question is the command-line odf-converter.

There is thus no explicit knowledge in OOo code of odf-converter in particular, just a generic mechanism for pre/postprocessing.

Novell builds odf-converter using Mono, and distributes it as a so-called bundled executable (platform-specific executable that includes the Mono runtime, i.e. not a platform-independent managed .NET executable) for Linux and Windows. For Linux the odf-converter is distributed as a .RPM package, for Windows as a OOo extension (.oxt file). These packages add their own xcu configuration snippets that define the OOXML file types and how to load and save them by using the pre/postprocessing stage.

And yes, once the built-in native OOXML support is good enough, there will be no need for odf-converter.

--tml


_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

Tor Lillqvist wrote:
>> will the OpenOffice.org integration for OdfConverter become obsolete?
>>    
>
> Well, the odf-converter (as the preferred spelling/casing is, I think) "integration" into OpenOffice.org is rather loose anyway. There is a patch in ooo-build that enables filters to run a separate preprocessing (when lolading) and postprocessing (when saving) program. When loading and saving OOXML formats this pre/postprocessing is used, and the program in question is the command-line odf-converter.
>
> There is thus no explicit knowledge in OOo code of odf-converter in particular, just a generic mechanism for pre/postprocessing.
>  
Hi Tor,

Yes, I noticed how the integration works, and I appreciate its
simplicity.  I am disappointed the preprocessing/postprocessing is not
yet (or ever will be?) integrated into the mainstream OpenOffice.org.  
It would be a solution to provide additional support such as Microsoft
Works word processor .wps which I developed in libwps.  Fridrich helped
and provided integration for upstream, but it was not accepted there for
various reasons.   As an alternative, it would have been relatively easy
to add .wps support as an extension the same way as odf-converter if the
pre-/post-processing support were upstream.  
> Novell builds odf-converter using Mono, and distributes it as a so-called bundled executable (platform-specific executable that includes the Mono runtime, i.e. not a platform-independent managed .NET executable) for Linux and Windows. For Linux the odf-converter is distributed as a .RPM package, for Windows as a OOo extension (.oxt file). These packages add their own xcu configuration snippets that define the OOXML file types and how to load and save them by using the pre/postprocessing stage.
>  
I was not aware of Mono bundled executables.  The OdfConverter binary
looks reasonably small, so I would not have guessed.
> And yes, once the built-in native OOXML support is good enough, there will be no need for odf-converter.
>  
Thanks.  I'm writing an article on the various options for OOXML support
for OpenOffice.org now (before OOo 3.0.0 is released).


Andrew
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Tor Lillqvist-3]

This question didn't get answered yet, I think:

> The add-in for Microsoft Office uses the same code to do the same in
> reverse, correct?   To save in .odt, MSO creates a .docx as a temporary
> file, then calls the binary to convert to .odt?

It uses the same code, but not by running a separate program. Hmm, actually now that I think of it I am not completely sure if it runs the conversion in a separate process or not. But anyway, yes, the actual format conversion uses the exact same pile of XSLT as the command-line odf-converter that one can use with OOo.

> 4. The credit above mentions Sun, but I don't see Sun mentioned here <
> http://odf-converter.sourceforge.net/>.   Is all the OpenOffice.org
> development for OdfConverter, including Sun's work,  going back into the
> SF.net project?

Here you are confusing the "native" OOXML filters with odf-converter. The native filter code is in C++ and written by people at Sun and Novell. odf-converter is in C# with the majority of the actual "business logic" in XSLT, and written by people at Clever Age and their subcontractors (or whatever).

> 5. The OdfConverter version from Sourceforge requires .Net framework
> 2.0, but the version from download.go-oo.org seems not to.

Do you mean the OOo build with the "native" OOXML filters included in the GoOo build of OOo in their work-in-progress state, or the odf-converter builds for Linux and Windows? The former have nothing to do with .NET at all. The latter don't require the .NET framework even if they are C# code as they are built as Mono "bundled" executables (i.e. include the Mono runtime and class libraries).

As such it is possible to use the upstream command-line odf-converter with OOo on Windows instead of the Mono-built executable.

--tml


_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

>  
>> 4. The credit above mentions Sun, but I don't see Sun mentioned here <
>> http://odf-converter.sourceforge.net/>.   Is all the OpenOffice.org
>> development for OdfConverter, including Sun's work,  going back into the
>> SF.net project?
>>    
>
> Here you are confusing the "native" OOXML filters with odf-converter. The native filter code is in C++ and written by people at Sun and Novell. odf-converter is in C# with the majority of the actual "business logic" in XSLT, and written by people at Clever Age and their subcontractors (or whatever).
>  
Yes, I was not clear on the distinction until it was pointed out today.
>  
>> 5. The OdfConverter version from Sourceforge requires .Net framework
>> 2.0, but the version from download.go-oo.org seems not to.
>>    
>
> Do you mean the OOo build with the "native" OOXML filters included in the GoOo build of OOo in their work-in-progress state, or the odf-converter builds for Linux and Windows?
I mostly meant GoOo (which I didn't know had native filters until
today), but I also meant odf-converter too.  :)    
> The former have nothing to do with .NET at all. The latter don't require the .NET framework even if they are C# code as they are built as Mono "bundled" executables (i.e. include the Mono runtime and class libraries).
>
> As such it is possible to use the upstream command-line odf-converter with OOo on Windows instead of the Mono-built executable.
>  



Andrew
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

[Fridrich Strba-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Ziem wrote:
~ Yes, I noticed how the integration works, and I appreciate its
| simplicity.  I am disappointed the preprocessing/postprocessing is not
| yet (or ever will be?) integrated into the mainstream OpenOffice.org.
| It would be a solution to provide additional support such as Microsoft
| Works word processor .wps which I developed in libwps.  Fridrich helped
| and provided integration for upstream, but it was not accepted there for
| various reasons.   As an alternative, it would have been relatively easy
| to add .wps support as an extension the same way as odf-converter if the
| pre-/post-processing support were upstream.

Andrew, you know, that if you wanted to make the filter an extension, it
should not be very difficult. You just compare what does the
STABLE-0-1-0 branch of wpg2odg, where I used to build a plugin wpg
importer. But be aware that as long as you release something, there will
be users and they will expect someone to fix bugs they find. Are you
ready to do that? Do you have the resources? Maintaining an OOo plugin
might be quite a work from my own experience.

Cheers

Fridrich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHlhJAu9a1imXPdA8RAr5bAJ496S8vRTrZxr5swUcmrIDwGwpp2QCePGFB
VC9kGRskqdDcsnWq2UHDdrI=
=aNDW
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org

Fridrich Strba wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Ziem wrote:
> ~ Yes, I noticed how the integration works, and I appreciate its
> | simplicity.  I am disappointed the preprocessing/postprocessing is not
> | yet (or ever will be?) integrated into the mainstream OpenOffice.org.
> | It would be a solution to provide additional support such as Microsoft
> | Works word processor .wps which I developed in libwps.  Fridrich helped
> | and provided integration for upstream, but it was not accepted there
> for
> | various reasons.   As an alternative, it would have been relatively
> easy
> | to add .wps support as an extension the same way as odf-converter if
> the
> | pre-/post-processing support were upstream.
>
> Andrew, you know, that if you wanted to make the filter an extension, it
> should not be very difficult. You just compare what does the
> STABLE-0-1-0 branch of wpg2odg, where I used to build a plugin wpg
> importer. But be aware that as long as you release something, there will
> be users and they will expect someone to fix bugs they find. Are you
> ready to do that? Do you have the resources? Maintaining an OOo plugin
> might be quite a work from my own experience.

Hi Fridrich,

You are right: I don't have much time.  That is why I have not pushed
for libwps to be upstream.  However, as an extension (vs. upstream)
there may be less users and therefore less work.  :)  Actually, as you
know, libwps has been in ooo-build, Ubuntu OOo, NeoOffice, etc., but I
have received few or no emails or bug reports in the 14 months or so
that libwps has been released.   It could be interpreted as a lack of
demand for wps conversion.


Andrew
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org