Saving SXD = Blank Doc

Saving a SXD file from Libreoffice 3.4.3 Draw results in a blank document
when reopening.

If the blank document is opened in Openoffice 3.3 it is also blank.

Openoffice 3.3 can create SXD file and open it, Libreoffice can also open
the SXD from Openoffice.

Hi :slight_smile:
It might be worth posting a bug-reoprt about it
http://wiki.documentfoundation.org/BugReport
Sorry that is not hugely helpful!

The newer odg might be better as the OpenDocument Format version 1.2 has been officially released now.  A lot of programs have been using ODF 1.2 for quite a long time already. 
Apols and regards from
Tom :slight_smile:

Yes I think I will submit a bug report, thought I would post here first as
suggested by the bug report page.

I am using the ODG format but one of my users had insisted to stay with the
old format and was complaining when I migrated them to Libre from Open.

Have a larger group of users that I want to eventually migrate over but
these two bugs will need to be fixed before I can.

Hi,

Boostland schrieb:

Saving a SXD file from Libreoffice 3.4.3 Draw results in a blank document
when reopening.

If the blank document is opened in Openoffice 3.3 it is also blank.

Openoffice 3.3 can create SXD file and open it, Libreoffice can also open
the SXD from Openoffice.

That is bug https://bugs.freedesktop.org/show_bug.cgi?id=41616.

Kind regards
Regina

Hi :slight_smile:
All good.

The older format 'should' be fine and the fact that it's not is a problem.  It was smart to try the list here.  Good move :)  It's still possible that someone here might be able to help but feel free to post the bug-report as soon as you like.

Regards from
Tom :slight_smile:

Hi,

Boostland schrieb:

Saving a SXD file from Libreoffice 3.4.3 Draw results in a blank document
when reopening.

If the blank document is opened in Openoffice 3.3 it is also blank.

Openoffice 3.3 can create SXD file and open it, Libreoffice can also open
the SXD from Openoffice.

That is bug https://bugs.freedesktop.org/show_bug.cgi?id=41616.

I like this part/comment:

Rainer Bielefeld 2011-10-09 23:52:53 PDT

...

Yes, it's dataloss, but are there really many users who still need .sxd?

Now that's the spirit!

Hi all,

I like this part/comment:

Rainer Bielefeld 2011-10-09 23:52:53 PDT

...

Yes, it's dataloss, but are there really many users who still need .sxd?

Now that's the spirit!

Just so that you all know, the engineering committe decided that legacy
filter _export_ support for the old StarOffice formats (SXS, SXW, SXD,
etc) would be phased out in the current 3.5 development tree (in fact, I
think it has already been deactivated).

Read support is still in, but will be optional for the build process,
i.e. dependent on a compile-time option.

What might have happened in 3.4.3 is that a patch from 3.5 got
back-ported (by mistake ?).

The T/ESC (technical/engineering steering committee) make public the
minutes of its meetings (posted on the wiki). If users want to know
what's going on, it is in the minutes of these meetings that they will
find out what's happening to the code.

Alex

Hi Alexander,

Alexander Thurgood schrieb:

Hi all,

I like this part/comment:

Rainer Bielefeld 2011-10-09 23:52:53 PDT

...

Yes, it's dataloss, but are there really many users who still need .sxd?

Now that's the spirit!

Just so that you all know, the engineering committe decided that legacy
filter _export_ support for the old StarOffice formats (SXS, SXW, SXD,
etc) would be phased out in the current 3.5 development tree (in fact, I
think it has already been deactivated).

As far as I understand it, only the binary formats will be disabled for writing. That's the file format from StarOffice5.2 with file extensions like sdw.

The SX* formats are packages with content.xml and styles.xml, similar to the ODF format.

Kind regards
Regina

Hi Regina,

As far as I understand it, only the binary formats will be disabled for
writing. That's the file format from StarOffice5.2 with file extensions
like sdw.

The SX* formats are packages with content.xml and styles.xml, similar to
the ODF format.

I hope you are right, else there will be a lot of unhappy users out
there (myself included).

I just had a thought that maybe this SXD export business is due to an
incorrect mimetype setting similar to the one we encountered on bugzilla
with the FlatXML ODG export filter and which was present in 3.4.0, 3.4.1
and 3.4.2 (but not in 3.4.3) ???

Alex

Hi Alexander,

Alexander Thurgood schrieb:

Hi Regina,

[..]

I just had a thought that maybe this SXD export business is due to an
incorrect mimetype setting similar to the one we encountered on bugzilla
with the FlatXML ODG export filter and which was present in 3.4.0, 3.4.1
and 3.4.2 (but not in 3.4.3) ???

I don't think so, because save as sxd was OK in LibO 3.4.2 but is broken in 3.4.3.

Kind regards
Regina

Link please.

And regardless of that (if correct), I find the commend by Rainer
Bielefeld on the bug to be unacceptable and disturbing.

Rainer is part of the QA Team & seems to head up the bug hunting seesion
efforts:
<http://wiki.documentfoundation.org/QA/QA_Team>
<http://wiki.documentfoundation.org/QA/IRCSessions#Monthly_Bug_Hunting_Sessions>

It's disturbing (to me) that Rainer dismisses the data loss altogether
after acknowledging it.

So if the QA team consider a 'who cares?' attitude towards data loss,
one an only wonder if the developers do the same...

Hi :slight_smile:
Would it be reasonably easy to generate a script to upgrade all the sxd's to ODF using 3.4.2 as a headless horseman?
Regards from
Tom :slight_smile:

The document converter wizard in 3.4.3 converts all the existing SXD
files over to ODG with no apparent issue.

Problem is if user decides to create a SXD file and ignores (or has
disabled) the warning about formatting and content that cannot be saved,
and then closes the document they will be rather annoyed when the open
it up again to find it is totally blank.

As it turns out, the minutes of the conference calls of the technical
steering committee are available on the developer mailing list :

news://snews.gmane.org/gmane.comp.documentfoundation.libreoffice.devel

Alex

...
Thanks. Any hint on which one I should be looking at? I can't seem to
find the reference in the 10/06/2011 minutes of tech. steering call ...

NoOp wrote (15-10-11 00:44)

As it turns out, the minutes of the conference calls of the technical
steering committee are available on the developer mailing list :

news://snews.gmane.org/gmane.comp.documentfoundation.libreoffice.devel

...
Thanks. Any hint on which one I should be looking at? I can't seem to
find the reference in the 10/06/2011 minutes of tech. steering call ...

I did a search for binfilter + minutes here
   http://lists.freedesktop.org/archives/libreoffice/

The minutes of tech steering call ... are the ones to look at.

Hi Gary,

NoOp wrote (14-10-11 03:18)

It's disturbing (to me) that Rainer dismisses the data loss altogether
after acknowledging it.

Hmm, does he really?
If he writes (comment #1)
    " Yes, it's dataloss, but are there really many users who
     still need .sxd? "
I mostly see a question :slight_smile:

Rainer is - as far as I know - known as a friendly and helpful person.

So if the QA team consider a 'who cares?' attitude towards data loss,
one an only wonder if the developers do the same...

I wonder if these are the kind of questions that will bring us further.
Developers always consider user questions and needs. Maybe sometimes have different view, or less/more information. So then we have to communicate about things, I guess.

Kind regards,

NoOp wrote (15-10-11 00:44)

As it turns out, the minutes of the conference calls of the technical
steering committee are available on the developer mailing list :

news://snews.gmane.org/gmane.comp.documentfoundation.libreoffice.devel

...
Thanks. Any hint on which one I should be looking at? I can't seem to
find the reference in the 10/06/2011 minutes of tech. steering call ...

I did a search for binfilter + minutes here
   http://lists.freedesktop.org/archives/libreoffice/

The minutes of tech steering call ... are the ones to look at.

Thanks Cor; I was looking for it in the most recent minutes. Found it:

http://lists.freedesktop.org/archives/libreoffice/2011-May/011485.html
<quote>
* announcing binfilter as deprecated in 3.4
  + want to warn people in plenty of time
  + officially deprecate it, we drop save support in 3.4
  + be warned - it will die in a new major release soon.
</quote>

However further in the thread:
http://lists.freedesktop.org/archives/libreoffice/2011-May/011573.html

Hi *,

2011/5/6 Pierre-André Jacquod <pjacquod at alumni.ethz.ch>:

[...]

        + be warned - it will die in a new major release soon.

Will be this 3.5 ? Or do you want to wait for the next version? If post 3.5,
then I will continue the cleaning. If no, I may change my work and try to
perform cleaning (ergh, deletion) as proposed here below.

Please at least have one release for people to be "warned" by lack of
write support.

But of course we can/should start communicating the removal of binfilter now.

ciao
Christian

And the 3.4.3 release notes do not indicate that write support has been
dropped:
http://www.libreoffice.org/download/release-notes/#LO343

Maybe it was thought that this blurb was sufficient:?
http://www.libreoffice.org/download/3-4-new-features-and-fixes/
Filters Features and Fixes
<quote>
Substantially re-work legacy StarOffice (pre 2000) binary file format
filters, removing all export code: the filters are now smaller and
read-only, this also removes clutter from the 'Save As' dialog
(Pierre-André Jacquod)
</quote>
??

[1]
http://www.informit.com/articles/article.aspx?p=30271&seqNum=8&rll=1

Hi Gary,

NoOp wrote (16-10-11 01:57)

Thanks Cor; I was looking for it in the most recent minutes. Found it:

Thanks for your reconstruction - anyway it looks to me like you did.

http://lists.freedesktop.org/archives/libreoffice/2011-May/011485.html
* announcing binfilter as deprecated in 3.4
[...]

[...]
And the 3.4.3 release notes do not indicate that write support has been
dropped:
http://www.libreoffice.org/download/release-notes/#LO343

As per git, commits for removing support were from 2011-04-24.
   http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=binfilter

So this might as well have landed in 3.4.1 ?
   http://wiki.documentfoundation.org/ReleasePlan

Maybe it was thought that this text was sufficient:?
http://www.libreoffice.org/download/3-4-new-features-and-fixes/
Filters Features and Fixes
[..]
??

Looks clear enough to me.
But if you mean better timing, or more profound announcement would have been good... I think so.
Alas mistakes are made here and there. Of course also by me (and I may have been involved in the notes/announcements - do not remember exactly).

http://www.informit.com/articles/article.aspx?p=30271&seqNum=8&rll=1

nice link :slight_smile:

Regards,

Looks like there is another bug involving the legacy file formats.

https://bugs.freedesktop.org/show_bug.cgi?id=45521

"Open sdw file save as odt or sxw close then reopen file and some data is
changed or lost, this happens on both the 3.5.0 RC2 and on 3.4.5 final.

This bug does not appear to be in the 3.3.4 release.

It is a major flaw as data loss can go unnoticed."