Bug 50430 - FILEOPEN: Can't Open .uop file
Summary: FILEOPEN: Can't Open .uop file
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: Other All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: BSA confirmed:4.3.3:windows confirmed...
Keywords:
Depends on:
Blocks: UOF mab4.3
  Show dependency treegraph
 
Reported: 2012-05-28 09:31 UTC by Rob Snelders
Modified: 2017-09-15 16:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of the error (119.42 KB, image/png)
2012-05-28 09:31 UTC, Rob Snelders
Details
Example uof-file from peking university (66.72 KB, application/octet-stream)
2012-12-02 14:47 UTC, Rob Snelders
Details
sample import result (16.56 KB, application/pdf)
2012-12-08 18:50 UTC, Peter Jentsch
Details
Empty presentation-file (131.71 KB, application/octet-stream)
2013-12-30 22:35 UTC, Rob Snelders
Details
Result of conversion of attachment 70928 (7.25 KB, application/vnd.oasis.opendocument.presentation)
2014-02-26 12:31 UTC, Mike Kaganski
Details
console error on opeing LO exported .uop UOF file (1.21 KB, text/plain)
2014-11-10 03:56 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Snelders 2012-05-28 09:31:17 UTC
Created attachment 62172 [details]
screenshot of the error

Problem description: 
When you save a empty presentation in uop-format, and open it then it gives an error. I'm not sure if the save or the load gives the error

Steps to reproduce:
1. Open Impress
2. Save file as Unified Office Format presentation (.uop)
3. Close Impress
4. Open Impress
5. Open the earlier saved file
6. You get the error attached

Current behavior:
Get an error and the file isn't opened

Expected behavior:
The file is opened

Platform (if different from the browser): 
Version 3.5.3 also has this problem
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Comment 1 Korrawit Pruegsanusak 2012-05-30 03:50:46 UTC
(In reply to comment #0)
> Version 3.5.3 also has this problem

I didn't test yet, but version field should be the earliest version that has problem. So, set version field accordingly.
Comment 2 Joel Madero 2012-11-03 17:01:33 UTC
Verified:

LibO: 3.6.1.2
LibO: Master
Bodhi Linux

Marking as NEW and prioritizing as BLOCKER + HIGHEST

Rationale:

Blocker: A user can go about making an entire presentation, save as UOP file and believe that their data is saved. They WILL NOT know that there is a problem until they try to open the file in which case they get a general input/output error. It looks like the data is corrupted upon save but I'm not positive on this one. Even if the data is not corrupted, the user would believe that the file is unusable unless they had alternative software to test on. 

High: We should never allow saving in a format that has the potential for a user to believe saving is occurring but then hit a general error with an unusable file. 

It can be argued that not many people save in this format but if we allow the format, we shouldn't have this kind of a bug. We should either remove the ability temporarily to save in this format or fix the bug :)
Comment 3 m.a.riosv 2012-11-03 18:26:47 UTC
Verified in:
MinGW Version 3.7.0.0.alpha0+ (Build ID: 1219bc)
Win7x64Ultimate
Comment 4 Caolán McNamara 2012-11-06 14:09:31 UTC
do we know of any version where this did work ?
Comment 5 Petr Mladek 2012-11-13 09:59:22 UTC
Heh, LO-3.4 does not show the error but the file is empty => it is data loss as well.

This bug can't block the release. It has been there for a very long time. It is a data loss but in a probably almost unused file format. In addition, we warn people about data loss when saving in non-ODF file formats.
=> lowering the severity. Well, it is completely broken, so we should do something about it => adding into MABs.
Comment 6 Petr Mladek 2012-11-13 10:02:59 UTC
It it newer worked reasonably, a perfectly fine solutions would be to disable it (at least the export).
Comment 7 tommy27 2012-11-13 13:09:18 UTC
some infos about .UOP files I found here: http://www.fileinfo.com/extension/uop

Presentation file created in the Uniform Office Format (UOF), an open document format created for Chinese office productivity applications; uses XML to describe the presentation and stores the presentation as a compressed archive.

UOP files are similar to .ODP files created with the the OASIS OpenDocument standard, but the formats are not compatible with each other.

UOP files can be opened with programs such as OpenOffice.org and LibreOffice.

---- 

so, as far as I see, saving as .uop has always been broken... and I agree with Peter that a temporary solution would be to disable it unless a fix is available (if the time effort is worth it)

but, what about reading .uop files generated by other softwares? 
does anybody have such a file to test?

according to that website, LibO should be able to open it.
Comment 8 Rob Snelders 2012-11-13 16:23:36 UTC
http://en.wikipedia.org/wiki/Uniform_Office_Format#cite_note-ooo-uof-2

Wikipedia doesn't state mutch more. There seems to be a converter for converting ODF to OUF. Maybe somebody can try that. I don't really have the time the coming week.
Comment 9 Rob Snelders 2012-12-02 14:45:43 UTC
It seems we can't load example UOF-files I found. Maybe block this file-format for now. (at least saving)
Comment 10 Rob Snelders 2012-12-02 14:47:42 UTC
Created attachment 70928 [details]
Example uof-file from peking university
Comment 11 Peter Jentsch 2012-12-07 23:12:02 UTC
The UOF presentation import is both formally and functionally broken. I'd be able to correct it formally (it contains some blanks in attribute matching rules), but also, it's rather incomplete: it doesn't handle a large amount of UOP element names, which leads to undetermined behaviour, depending on the XSLT processor being used.
Comment 12 Peter Jentsch 2012-12-07 23:16:15 UTC
AOOO 3.4.1 doesn't open file either. Insists on opening as plain text file, even if explicitly asking to open as UOF.
Comment 13 Joel Madero 2012-12-07 23:16:31 UTC
I think if it can't be fixed by release of 4 we need/should take out the ability to save in this format until further notice.
Comment 14 Joel Madero 2012-12-08 00:31:41 UTC
Actually looking at 3.6.3.2 I can't seem to find that format, was it removed from the list? If so should we edit the title of this to say something like "fix and re-enable uop support"?
Comment 15 Peter Jentsch 2012-12-08 18:50:28 UTC
Created attachment 71215 [details]
sample import result

Attaching a pdf that shows the Example UOF file after fixing the obvious formal errors in the import filter. 

I'm unable to verify if this result is meaningful. If it's usable I'd just commit the fix and we close the issue. If it's unusable I'd suggest to move the UOF filters to an extension, and let users know about the incompleteness of the filters on the download page for the extension.
Comment 16 tommy27 2013-06-23 10:36:07 UTC
hi, is there anybody with a valid .uop file with non-chinese text that we may try to convert with Peter fix, and see if it solves the issue?

unfortunately I cannot find any useful .uop file in the web... this makes me think that this format is not much used.
Comment 17 tommy27 2013-07-30 19:46:22 UTC
still reproducible in LibO 4.1.0.4
Comment 18 tommy27 2013-08-01 11:45:33 UTC
I ask again for a sample non-chinese .uop file to test Peter Jentsch fix.

We should fix this .uop incompatibility since there're many places over the internet where LibO is considered the recommended software to open .uop files.

see this link: http://file.downloadatoz.com/uop-file-extension/
Comment 19 tommy27 2013-08-17 16:33:10 UTC
moving this from the mab3.6 list to the mab4.0 list since 3.6.x is EOL.

we have a potential fix by Peter Jentsch that has not been tested yet because of lack of a non-chinese document.

I suggest to committ it anyway since in any case it could not be worse than actual situation where LibO cannot save or open at all those UOP files.
Comment 20 Rob Snelders 2013-09-25 15:40:25 UTC
It seems to work in AOO4.0.

So there documents can be made/
Comment 21 tommy27 2013-09-25 19:46:43 UTC
@Rob
could you please provide a sample .UOP in non-chinese text?
it if works in AOO 4.0 it means that they found a fix (Comment 12 says AOO 3.4.1 had this bug too)
Comment 22 tommy27 2013-09-25 19:51:17 UTC
(In reply to comment #20)
> It seems to work in AOO4.0.

are you sure? I've just tried right now to open in AOO 4.0.0 your "Example uof-file from peking university" and I still get the same error message as in LibO
Comment 23 Rob Snelders 2013-09-25 20:50:04 UTC
I'm not sure at the moment about the exact status in AOO4.0. I will try to find out more when I'm back from the LO-conference.

For now I just tried to save a empty document in AOO4.0 and load that document again. It loads. No other tests done at the moment, but it is further than LO4.0 gets.
Comment 24 Rob Snelders 2013-09-30 20:41:13 UTC
AOO4.0.0 has 2 versions of the uop-format. They are called:
- Uniform Office Format presentation (.uop)
- Uniform Office Format 2 presentation (.uop)

In both formats I can save a document and open it again in AOO

But both saves can't be opened in LO4.1.1.2

If I save in LO with the .uop-format it opens in AOO. It seems we save in the first version of the format.
Comment 25 tommy27 2013-12-19 02:32:19 UTC
(In reply to comment #24)
> ...
> If I save in LO with the .uop-format it opens in AOO. It seems we save in
> the first version of the format.

please attach a test . uop file so I can test.
Comment 26 Rob Snelders 2013-12-30 22:35:59 UTC
Created attachment 91350 [details]
Empty presentation-file

This is a empty presentation in the format saved with LibreOffice 4.1.4.2.

Just created a new presentation (default template) and saved it in UOP-format.
When I open it again I get the error.
Comment 27 tommy27 2013-12-31 14:07:52 UTC
test file cannot be opened in LibO 4.1.4.2 and 4.2.0 RC1
AOO 4.0.0 cannot open it too.
Comment 28 Maxim Monastirsky 2013-12-31 15:36:12 UTC
The bug with opening UOP consists of two problems:

1) The xsl files were written with Xalan in mind, and they don't work with libxslt (which is what LO uses currently). Just try it yourself:

This will output several errors in xsl files:
$ xsltproc --output out.fodp /usr/lib/libreoffice/share/xslt/import/uof/uof2odf_presentation.xsl test.uop

But this will output a valid Flat ODF presentation:
$ xalan -in test.uof -out out.uof -xsl /usr/lib/libreoffice/share/xslt/import/uof/uof2odf_presentation.xsl

2) The output fodp file doesn't contain "office:mimetype="application/vnd.oasis.opendocument.presentation", so XML detection code can't detect it.
Comment 29 Maxim Monastirsky 2013-12-31 16:11:13 UTC
(In reply to comment #28)
> 2) The output fodp file doesn't contain
> "office:mimetype="application/vnd.oasis.opendocument.presentation", so XML
> detection code can't detect it.
In fact it should detect the uop (there is no fodp file), so it's not a bug.
Comment 30 Björn Michaelsen 2014-01-17 09:58:30 UTC Comment hidden (obsolete)
Comment 31 stragu 2014-02-12 08:18:39 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 32 Mike Kaganski 2014-02-26 12:31:46 UTC
Created attachment 94765 [details]
Result of conversion of attachment 70928 [details]

FYI: http://odf-to-uof.sourceforge.net/ contain an open-source bi-directional converter developed by Open Standard Lab of Peking University; attached is the result of conversion of "Example uof-file from peking university" (attachment 70928 [details]) to ODF.

Also, there are a number of sample documents, and a comparison of ODF to UOF.
Comment 33 David Tardon 2014-02-26 13:00:44 UTC
(In reply to comment #32)
> FYI: http://odf-to-uof.sourceforge.net/ contain an open-source
> bi-directional converter developed by Open Standard Lab of Peking
> University; attached is the result of conversion of "Example uof-file from
> peking university" (attachment 70928 [details]) to ODF.

Which is a code dump from 2006 (to be honest, that is really not so different from our internal UOF import/export code .-) Moreover, it is written as a GUI application in Java, in a rather horrible style.
Comment 34 tommy27 2014-04-30 19:43:48 UTC
retested attachment 70928 [details] under Win7x64 using 4.2.3.3 and 4.3.0.0.alpha0+ (22 apr build)

I do not see error messages (like in attachment 62172 [details]) but the file is opened in LO Writer showing incomprehensible text like:

<?xml version="1.0" encoding="UTF-8"?>
<uof:UOF xmlns:uof="http://schemas.uof.org/cn/2003/uof" xmlns:图="http://schemas.uof.org/cn/2003/graph" xmlns:字="http://schemas.uof.org/cn/2003/uof-wordproc" xmlns:表="http://schemas.uof.org/cn/2003/uof-spreadsheet" xmlns:演="http://schemas.uof.org/cn/2003/uof-slideshow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.uof.org/cn/2003/uof D:\UOF\uof_schema\uof.xsd" uof:language="cn" uof:version="1.0" uof:locID="u0000"><uof:元数� uof:locID="u0001"><uof:创建者 uof:locID="u0004">xie</uof:创建者><uof:最�作者 uof:locID="u0006">xie</uof:最�作者><uof:创建日期 uof:locID="u0008">2006-09-20T14:18:05</uof:创建日期><uof:编辑次数 uof:locID="u0009">1</uof:编辑次数><uof:编辑时间 uof:locID="u0010">P0Y0M0DT0H4M23S</uof:编辑时间><uof:创建应用程� uof:locID="u0011">EIOffice 2007</uof:创建应用程�><uof:关键字集 uof:locID="u0014"><uof:关键字 uof:locID="u0015"></uof:关键字></uof:关键字集><uof:公��称 uof:locID="u0018">pku</uof:公��称></uof:元数�><uof:对象集 uof:locID="u0033"><图:图形 uof:locID="g0000 

etc. etc.
Comment 35 tommy27 2014-05-01 08:24:47 UTC
4.1.x reached end of life.
moving this still reproducible bug to mab4.2 list.
Comment 36 oscar valenzuela 2014-10-26 19:25:48 UTC
Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64
Comment 37 V Stuart Foote 2014-11-09 19:49:36 UTC
@David T., Peter J., *,

With pending review of the 4.2 MAB had a look at this bug.

On a current build of 4.4.0.0alpha2 master, can save from Impress, Writer to corresponding UOF format, i.e. .uop, .uot--a visual inspection of the resulting XML shows what appears to be well formed content. The strings inserted into the document are visible.  The LibreOffice generated .uot will open (with Writer set to CM or MM as in bug 73292), but the .uop will throw the same "Genereal Error. General input/output error." as with the OP on LO 3.5.3

And when importing the sample comparison files from the Bejing University ODF-UOF Conversion utility (2006) the documents, all labeled with .uof, documents will only display as unformatted XML text in writer, as tommy27 reports in comment 34--so guess there may be a MIME type or XLST issue in recognizing the UOF needing to be filtered on opening.

@Peter J. -- did you ever arrange to push your patch to clean up the presentation filter? I didn't see it looking through cgit...

Which leaves us the current state of the import and export filters for UOF v1.0 format as here:
http://opengrok.libreoffice.org/xref/core/filter/source/xslt/import/uof/
http://opengrok.libreoffice.org/xref/core/filter/source/xslt/export/uof/

There have been a few minor tweaks on the export filters, but mostly they remain as originally merged by Li Yuan into OOo CWS from definitions of the 2006 v1.0 of Chinese national standard.

I went looking for the Liu Jiaxiang's April 2010 OOo CWS submission referred to in https://issues.apache.org/ooo/show_bug.cgi?id=110348 c#4 but that looks to have been purged from the AOO CWS.  I'd hoped to compare the XLST of those proposed changes to the XLST provided in the "ODF-UOF-Converter" Java. Anyone with ideas in that regard?

Other than getting the original UOF 1.0  import/export filter functioning,
I guess the question is--how important is interoperability for our Chinese language L10n users to have reliable UOF interchange with the current Chinese standard?  I suspect it is still rather important to have this correct.
Comment 38 V Stuart Foote 2014-11-09 20:01:16 UTC
(In reply to V Stuart Foote from comment #37)
Correct that... %:s/XLST/XSLT/g
Comment 39 V Stuart Foote 2014-11-10 03:56:33 UTC
Created attachment 109184 [details]
console error on opeing LO exported .uop UOF file

On Fedora 20 32-bit LXDE with debug build
Version: 4.4.0.0.alpha1+
Build ID: d59b9b4af36148e4d8df8f3e3492116d378642e2
TinderBox: Linux-rpm_deb-x86@45-TDF-dbg, Branch:master, Time: 2014-11-06_03:11:43

When reopening a .uop presentation saved from LibreOffice, on import we are getting an XML parse errors from the XSLT transform--the XSLT aborts on the errors. And then get the General Input/Output Error dialog, but no crash.

Looks like maybe just need some cleanup of the http://opengrok.libreoffice.org/xref/core/filter/source/xslt/import/uof/uof2odf_presentation.xsl filter to remove an extra space, on line 1344 and line 2748.
Comment 40 tommy27 2014-11-20 05:49:24 UTC
still reproducible in LibO 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18

LibO 4.2.x reached the end of life.
moving this mab4.2 to mab4.3 list.
Comment 41 Peter Jentsch 2014-11-28 12:57:10 UTC
It's indeed correct, that importing fails because of one leading and one trailing space in the XSLT file.

leading blank character before "<xsl:attribute name=" style:text-underline-color">"

trailing blank character after "<xsl:attribute name="smil:repeatCount ">
Comment 42 tommy27 2014-11-29 04:51:36 UTC
hi Peter, 
so would it be a easy hack to fix this and finally get rid of this old MAB?
Comment 43 Commit Notification 2015-01-06 08:35:08 UTC
Peter Jentsch committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=79412ad26ce1e0a9da5295357ea8892433d6d0a3

fdo#50430: UOP import failed because of leading and trailing space in XSLT.

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 44 Jan Holesovsky 2015-01-06 08:35:59 UTC
Peter was correct in comment 41, removing these spaces indeed fixed that.

Peter - thank you! :-)  I've pushed the fix with your name as the author, hope that's fine.
Comment 45 Commit Notification 2015-01-06 09:04:30 UTC
Peter Jentsch committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9417a42c29bcd695471736c944c7144f7b275229&h=libreoffice-4-4

fdo#50430: UOP import failed because of leading and trailing space in XSLT.

It will be available in 4.4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 46 vihsa 2017-07-01 11:31:57 UTC
attachment 70928 [details] and attachment 91350 [details] does not

[1] list in file browser
[2] open in libreoffice viewer

Version: 6.0.0.0.alpha0+
Build ID: 643da8ec4e721d33dfdf8d78bedd50a915f1188d TinderBox: Android-ARM@24-Bytemark-Hosting, Branch: Master, Time: June 26, 2017 01:29:17