Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Formulae from long Word documents
Formulae from long Word documents
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
xja
Operator


Joined: Dec 27, 2006
Posts: 40

PostPosted: Thu May 01, 2008 10:00 am    Post subject: Formulae from long Word documents

Hello,
I think that the conversion of Equation formulae in Neo is great, but there should be some improvements in displaying those formulae correctly, especially in long documents.
This is a screenshot of a formula in a long Word document opened in Neo

Then I double click it to edit and displays correctly


This is a rather little problem viewing on the computer, but it's annoying when printed.

Bye.
Back to top
xja
Operator


Joined: Dec 27, 2006
Posts: 40

PostPosted: Sat May 03, 2008 7:00 am    Post subject:

Nobody has a clue of what could be the cause of the issue?

Bye.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sat May 03, 2008 9:35 am    Post subject:

If you used Microsoft Office to create the formula, then I think I know what you are seeing. When Office or the MathType application save a formula object, they save the file as an OLE object. An OLE object is a special file format created by Microsoft that contains the following two things:

1. An snapsnot image of the object you saved
2. The actual data you saved in its native format

When you open a document with an OLE object, NeoOffice's underlying OpenOffice.org code grabs the first item - the snapshot image - and draws it. Only when you double-click on the OLE object will NeoOffice's underlying OpenOffice.org read and draw the second item - the actual data - as parsing the actual data may fail if it is of an unknown native format and parsing, if it does not fail, can take significantly more time than reading and drawing the snapshot image.

In theory, the snapshot image should look identical to the actual data. However, in the case of Office and MathType equations, the snapshot image is in the PICT image format. Unfortunately, the OpenOffice.org code does not have the most robust PICT image importer as we found in bug 2977 so placement of text can be appear incorrect.

Patrick
Back to top
xja
Operator


Joined: Dec 27, 2006
Posts: 40

PostPosted: Sun May 04, 2008 2:13 am    Post subject:

Yes, those equations were created in MSOffice.
A PICT image is a vectorial image, right? otherwise the bars on the brackets are not possible.
Clearly, they do this to reduce the size.
So we have to wait for OOo to fix that? or you are already working on that bug?

Thanks.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sun May 04, 2008 9:46 am    Post subject:

xja wrote:
Yes, those equations were created in MSOffice.
A PICT image is a vectorial image, right? otherwise the bars on the brackets are not possible.
Clearly, they do this to reduce the size.
So we have to wait for OOo to fix that? or you are already working on that bug?

Thanks.


I am sorry to say that at this point, there are the following PICT importing issues that we will not be able to fix as we are limited by either the general OOo application code or by the fact that we do not have access to Apple's proprietary PICT parsing source code:

1. Text overlap - OOo's text layout engine rounds glyph positions to the nearest integer. As a result, this rounding of native glyph kerning can cause text strings to be slightly longer or shorter than in other native applications. This behavior can be seen in the slight overlap when displaying the attached Ancestors.pct file

2. Text too large - Some PICT creators like MS Office appear to make extensive use of PICT comment fields to denote a text frame. Text drawn within such a frame is apparently supposed to be scaled to fit with the frame bounds. Unfortunately, I have had no success identifying what the comment field codes mean and what data structures are used for each comment field. This behavior can be seen in the attached 2GC-Migration-Test.ppt file where in the lower right image, the text height and width for each line is too large.

3. Saving - When saving any PICT file or any document with embedded PICT images, the OOo code will not use the original PICT data. This prevented me from using Apple's functions to convert the PICT data to EPS data which is a vector format that NeoOffice can handle. While doing such a conversion produced high quality rendering of the PICT data, saving any PICT file or document with PICT images produced empty images. Also, this same OOo limitation causes PICT data in MS Office documents to be saved as WMF data, not PICT.

4. Embedded QuickTime images - The PICT format allows embedding of QuickTime images. Unfortunately, the Apple PICT conversion functions will hang when converting the QuickTime images in the attached 2GC-Migration-Test.ppt file so these embedded images are ignored in our code. In the attached 2GC-Migration-Test.ppt file, the embedded QuickTime images are the shading around the elliptical items.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.