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
(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.
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 :)
Verified in: MinGW Version 3.7.0.0.alpha0+ (Build ID: 1219bc) Win7x64Ultimate
do we know of any version where this did work ?
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.
It it newer worked reasonably, a perfectly fine solutions would be to disable it (at least the export).
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.
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.
It seems we can't load example UOF-files I found. Maybe block this file-format for now. (at least saving)
Created attachment 70928 [details] Example uof-file from peking university
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.
AOOO 3.4.1 doesn't open file either. Insists on opening as plain text file, even if explicitly asking to open as UOF.
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.
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"?
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.
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.
still reproducible in LibO 4.1.0.4
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/
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.
It seems to work in AOO4.0. So there documents can be made/
@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)
(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
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.
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.
(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.
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.
test file cannot be opened in LibO 4.1.4.2 and 4.2.0 RC1 AOO 4.0.0 cannot open it too.
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.
(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.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
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.
(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.
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.
4.1.x reached end of life. moving this still reproducible bug to mab4.2 list.
Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64
@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.
(In reply to V Stuart Foote from comment #37) Correct that... %:s/XLST/XSLT/g
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.
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.
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 ">
hi Peter, so would it be a easy hack to fix this and finally get rid of this old MAB?
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.
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.
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.
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