PLUGIN UPDATED


added exportData.ODF to export data to OpenFormula files.


[edit] when possible, the default output is: formula as defined = symbolical formula (variables replaced with numbers) = numerical output value

direct assignment: data to export written inside exportData.ODF 1st argument.


best regards,

w3b5urf3r

Edited by user 12 January 2013 18:37:45(UTC)  | Reason: Not specified

Hi Martin,

I think it's a good standardization, I'll do it in the next relase


I don't know how to do it, but I'm working to save the entire sheet as an ODT document


best regards,

w3b5urf3r

Edited by user 13 January 2013 12:59:40(UTC)  | Reason: Not specified

You are right, .NET 3.5 works without problems (f.e. I've seen that the DocxFileType plugin works under .NET 3.5 and does not cause issues)

Obviously now an *.xlsx import/export feature could be added

[edit] exportData.XLSX and importData.XLSX fully implemented

Edited by user 14 January 2013 20:10:07(UTC)  | Reason: Not specified

PLUGIN UPDATED

REQUIREMENTS: .NET Framework required version upgraded to 3.5

• added "Save as" odt files:
  - editable equations;
  - text formatting like SMath worksheet (size, colors, style:bold/italic/underline);
  - page size & orientation like SMath worksheet.
  
• added exportData.XLSX and importData.XLSX
  
• ODF formulas:
  - added: el(3), range(2), range(3), sys(), all trigonometric functions, subscripts, absolute variables (~variable), empty values (#), nested quotes.
  - units: typeset, multiplication symbol;
  - text: added quotes, alignments inside matrices;
  - programming: added line()*, if/else, for(3), for(4), while();
  - booleans: fixed comparision symbols issues;
  - general: fixed conflicts with reserved words and symbols, output markup adjustements.
  
• dynamic assistance adapted to multilanguage (ENG/ITA implemented, send me a PM with your translations to have more languages)
  
• exportData.CSV and exportData.ODS enhanced to export even unassigned variables.

* when there is a variable/function defined with a line(), the right side could be higher than the left side; simply add some #{} after the = sign to pull up the left side.


best regards,

w3b5urf3r

Edited by user 17 January 2013 14:28:06(UTC)  | Reason: Not specified

Hi, I think not (at least doesn't work for me); I attach here a .NET 4 DataExchange.dll but in my PC this cause that SMath disable the plugin. If you can install the framework, here there is the .NET framework 3.5 from Microsoft website (no registration required). If you can't I can add a .NET 2.0 plugin without XLSX support.

---
Ciao, non credo o almeno a me non funziona... ti allego la versione compilata per .NET framework 4 ma a me disabilita la plugin all'avvio. Comunque se hai la possibilità di installarlo il framework lo puoi trovare nel sito Microsoft senza registrazione .NET framework 3.5. Se non puoi, posso comunque aggiungere ai download una plugin "ristretta" senza il support ai file XLSX per .NET framework 2.0.

Edited by user 17 January 2013 17:32:54(UTC)  | Reason: Not specified

Seeking to understand the problem, I saw that .NET framework 3.5 it's an upgrade of 2.0 version and .Net framework 4 it's a completely new framework; all can be installed on the same system (but version 3.5 doesn't work without 2.0) and at least in theory any windows 7 system contains a built-in .NET framework 3.5... Maybe my first idea could be wrong, so could you make a screenshot of the issue?

However I've uploaded in the first post an updated version of DataExchange plugin, without XLSX functions, for .NET 2.0 systems.

---
Ho guardato un pò in giro cercando di capire quale possa essere il problema... Il framework 3.5 è un'estensione del 2.0 mentre il 4 è una cosa completamente nuova ed indipendente; tutti e tre possono essere installati sullo stesso computer (ma il 3.5 non funziona senza il 2) e, almeno in teoria, windows 7 ha il 3.5 nativo essendo basato su di esso (e per questo non lo si trova in installazione/applicazioni). Quindi potrebbe anche essere che la mia "diagnosi" sia sbagliata.. potresti fare una copia del messaggio di errore (con la plugin 3.5 ovviamente)?

Ad ogni modo nel primo post ho aggiunto un link alla plugin aggiornata basata sul framework 2.0; è più leggera ma ovviamente non supporta lo scambio dati con i files XLSX.

Ciao!
---


best regards,

w3b5urf3r

Edited by user 17 January 2013 22:34:54(UTC)  | Reason: Not specified

Hello W3bsurf3r
thank you for the odt-export feature, great work! It works really fine and I like the formatting. I observed the following issues:

- Images (from image or plot regions) are shrunk to a small thumbnail when loading exported odt files. The images seem to have the correct resolution and size information, but some odd scaling factors are applied. Once they are reset to 100%, you get the correct size and aspect ratio of the images.

- Word 2010 can read odt files directly. However, it fails to read the files exported by your plugin. Once I read the odt into Libre- or OpenOffice Writer and save it again as odt, then Word can read the file (one has to ignore the annoying complaints about damaged contents). May be, by adjusting the odt format the plugin could gain direct Word connectivity.

How about bringing the Latex-Plugin by Andrey to the Level reached by your odt export?

Martin

Hi Martin,

thank you for your feedbacks

Using LibreOffice 3.6 and 4.0 on my system I can't see the image size issues... could you attach a plugin-saved odt and odf and the re-saved files from your office application?

The Latex-Plugin it's the root of *.odf and *.odt features of DataExchange plugin, so update the plugin with new enhancements it's not a big issue; unfortunately my latex is very basic, so probably it will take some time


regards,

w3b5urf3r

Edited by user 18 January 2013 20:09:43(UTC)  | Reason: Not specified

Try the attached DataExchange.dll

images now have the correct size, thank you for the bug fix. Also, direct word read in is possible (zugstab-export-1.odt). However, in this case only images and text regions are read, all math regions (formulas) are broken.

Intermediate load and save with libreoffice (zugstab-export-LO-1.odt) improves the word import, still the formatting of control structures is broken.

In general, opening both odt files with word generates error messages. If saved as docx from Libreoffice, then Word can read the file cleanly, still formatting is broken (mainly due to centering of math items)

Martin