From: SourceForge.net <no...@so...> - 2007-06-28 01:37:36
|
Feature Requests item #991541, was opened at 2004-07-15 21:13 Message generated for change (Comment added) made by brandelune You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520350&aid=991541&group_id=68187 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: future Status: Open Resolution: None Priority: 9 Private: No Submitted By: Maxym Mykhalchuk (mihmax) Assigned to: Nobody/Anonymous (nobody) Summary: New filters: MSOffice Initial Comment: (part of "far future" wishlist) OmegaT should be able to read and write out the files of MSOffcie family, namely MS Word and MS Excel. Currently it's discussed what approach can we choose to handle these files: MSWord->HTML->OmegaT->HTML->MSWord + Requires little extra code - Doesn't preserve formatting well - Costs the price of msword - Works on Windows only MSWord->WordML->OmegaT->WordML + Preserves 100% formatting - Only a few people have Office2003pro. - Works on Windows only - Requires writing new custom filter - Costs the price of msword MSWord->OO->OmegaT->OO->MSWord + Preserves 90% formatting + Works on MacOSX & Linux + Free (does not cost the price of msword) - Doesn't preserve 10% formatting - Requires installing OO ---------------------------------------------------------------------- >Comment By: Jean-Christophe Helary (brandelune) Date: 2007-06-28 10:37 Message: Logged In: YES user_id=915082 Originator: NO I think the consensus is that we only have a documentation issue here, especially with the support of MSO12 files in the recent builds. Shall I move this issue to the documentation tracker and assign it to myself ? ---------------------------------------------------------------------- Comment By: Henry Pijffers (henry_pijffers) Date: 2007-02-20 02:47 Message: Logged In: YES user_id=545103 Originator: NO With the recent MS OpenXML format, I think support for legacy MS Office formats is no longer a necessity. People can simply resave their .doc files as .docx, even with older versions of MS Office. It's just a matter of documenting that. OmegaT could even detect .doc files and instruct the user to resave as .docx, and refer to the help file for more instructions. ---------------------------------------------------------------------- Comment By: Didier Briel (didierbr) Date: 2007-02-17 19:24 Message: Logged In: YES user_id=1343245 Originator: NO <<All the suggestions we've had that far discussed ways to "hide" the conversion process from the eyes of the user.>> It seems to be important for some. <<Which is not like DOC support.>> It is in line with the purpose of this RFE. Didier ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2007-02-17 09:03 Message: Logged In: YES user_id=915082 Originator: NO Didier, I know all that. What I mean is that now that DOCX and his cousins are supported there is not much more that we can do to get OmegaT to support directly the legacy formats. All the suggestions we've had that far discussed ways to "hide" the conversion process from the eyes of the user. Which is not like DOC support. I think what we have now is a documentation issue where we have to explicit all the options somewhere. ---------------------------------------------------------------------- Comment By: Didier Briel (didierbr) Date: 2007-02-17 02:31 Message: Logged In: YES user_id=1343245 Originator: NO <<Is there anyway this can be implemented ?>> You can check the discussion on these in the mailing list. The library Sonja mentioned was discussed, as well as the "Macro plus --invisible" approach. Didier ---------------------------------------------------------------------- Comment By: Maxym Mykhalchuk (mihmax) Date: 2007-02-16 22:06 Message: Logged In: YES user_id=488500 Originator: YES dunno I've just seen Sonja's e-mail that she can't find this issue, so I thought it'd be better if I reopen it so that it can be found easier. ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2007-02-16 21:29 Message: Logged In: YES user_id=915082 Originator: NO Is there anyway this can be implemented ? Even using OOo future libraries that would mean conversion (internal) to ODF, no ? ---------------------------------------------------------------------- Comment By: Maxym Mykhalchuk (mihmax) Date: 2007-02-16 19:01 Message: Logged In: YES user_id=488500 Originator: YES Reopening so that we don't forget this RFE... It is different from #1589239 because this is about support for old-style MSOffice .doc/.xls/etc files. ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2006-11-08 01:02 Message: Logged In: YES user_id=915082 Looks like it can be considered a duplicate of 1589239 (support for MSO 12 XML format). The library Sonja mentioned seems to have evolved a lot, but still requires a conversion through OOo, which is always worse than direct support through MSO12 conversion. http://jooreports.sourceforge.net/?q=jooconverter ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2006-02-23 09:26 Message: Logged In: YES user_id=915082 Thanks to Sonja for unearthing this old RFE of mine :) JC ---------------------------------------------------------------------- Comment By: Maxym Mykhalchuk (mihmax) Date: 2006-02-23 02:34 Message: Logged In: YES user_id=488500 Thanks a lot, Sonja. Now I think this is the top-priority for next OmegaT release. I think it will require a bit of work on OO filter itself, apart from integrating JOOConverter, but I think it's worth it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-02-23 00:13 Message: Logged In: NO In addition to this (very) old RFE, I am adding this link to a Java library that would still require the use of OOo (i.e., users must install it first before they can use it), but the conversion could then be processed from within OmT, and users wouldn't have to open OOo first. Link: http://sourceforge.net/projects/joott I also posted it to the OmTdev group. Sonja ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2005-09-21 12:16 Message: Logged In: YES user_id=915082 It has to be mentioned that the next version of Office (Office 12) will shift from a binary format to a XML+ZIP format a la OpenOffice. The format will be usable without having to pay licencing fees, which means that OmegaT will be able to propose MSOffice direct filtering for free (well, at the cost of the time it takes to create the filters...) ---------------------------------------------------------------------- Comment By: Jean-Christophe Helary (brandelune) Date: 2004-10-27 12:49 Message: Logged In: YES user_id=915082 MSWord->HTML->OmegaT->HTML->MSWord +Preserves formatting well enough (very little meta data loss) +Works on any platform that has MS Office (MacOSX incl.) -MS Html is crap and induces extra processing time within OmegaT. MSWord->WordML->OmegaT->WordML -WordML is a very unorthodox xml (as one can see at: http://www.oreilly.com/catalog/officexml/chapter/ch02.pdf and http://examples.oreilly.com/officexml/) and would require a very specific parser. Another approach that is based on the MSWord->OO->OmegaT->OO->MSWord concept is to access OmegaT from within OO (or variants like NeoOffice) like a CAT macro a Wordfast. Most "business" translators would favor an integrated approach that makes real use of their Office suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520350&aid=991541&group_id=68187 |