LibreOffice Portable now runs from paths with spaces

[JohnTHaller]

With the recent LibreOffice Portable 3.4.3 and 3.3.4 releases, PortableApps.com has added the ability for LibreOffice Portable to be able to run form a path with spaces, making it the first and only OpenOffice.org variant to do so. We've made it available as an add-on to the main release to allow adequate time for folks to test it out with various LibreOffice add-ons to ensure it won't break something not in the main package. You can get the add-on to enable spaces in the LibreOffice Portable installation path here. Please report any issues back in that posting. Enjoy!

[Taf]

SNIP...PortableApps.com has added the ability for LibreOffice Portable to be able to run form a path with spaces, making it the first and only OpenOffice.org variant to do so. ...SNIP

Hi John, it's nice to know that! Finally also LibreOffice Portable has implemented this feature but, I want to remember you all, the "X-Versions" are downloadable since:
08-18-2011 (3.3.4) -> http://www.winpenpack.com/en/download.php?view.1301
09-04-2011 (3.4.3) -> http://www.winpenpack.com/en/download.php?view.1323

and both of them do NOT suffer problems if you "install" in a path with spaces (as You can see also here: http://www.portablefreeware.com/forums/ ... 237#p33237)!

So, I'm sorry John, but PA is Neither the first nor the only!"

With Kind Regards

[JohnTHaller]

Hi John, it's nice to know that! Finally also LibreOffice Portable has implemented this feature but, I want to remember you all, the "X-Versions" are downloadable since

Ah, I see I was mistaken. Sorry about that. The last time Danix had said spaces were supported, X-LibreOffice simply crashed hard in LibreOffice itself (no friendly warning like LibreOffice Portable) since spaces were still an issue. It seems that spaces seem to be working now. I must have tested a previous version by accident.

Unfortunately, X-LibreOffice is using a buggy implementation, so while spaces now work, X-LibreOffice has other issues. For instance, sometimes when I alter the directory path, X-LibreOffice crashes out on launch without error and needs to be started a second time, while LibreOffice Portable with our spaces patch continues working with the same path changes. (From X:\PortableApps\LibreOffice to X:\PortableApps\Libre$Office for example). As you're using encoding on the path but only encoding a space to a %20 without encoding any other characters, this could be part of the issue. We're not using encoding on that same bootsrtap path and instead using a relative path that will not contain that special character, so that could very well be it.

On a related note, the $ is a special character in LibreOffice and X-LibreOffice isn't handling it properly. When run in the above example, X-LibreOffice creates an additional X:\PortableApps\Libre directory and stores some things in it. LibreOffice Portable with our spaces patch correctly handles the $ character. Again, I'd wager this is related to your partial implementation of encoding.

I noticed some additional issues in testing, so you're aware of them. First off, there seems to be no option at all to keep more than one language, which is a bit user-unfriendly and something that I know several users of LibreOffice Portable enjoy. You're stuck with English and one other language with no option at all to retain multiple languages the way LibreOffice Portable can. This isn't made clear at all by the first-run screen you're presenting to users. Especially since I couldn't see a way to get that initial screen to come up in a language other than English and the defaults include English-only. If I try to cancel that screen (natural instinct for a screen that's not understandable), I get an "Installation cancelled by user" error, then a prompt to install Java (which I also cancel), then LibreOffice tries to start and crashes, then I get the language selection screen AGAIN, which I cancel, then I get prompted to install Java again, which I cancel, then finally LibreOffice starts. As first run behavior goes, that's quite user-unfriendly.

As concerns Java, the Java Get prompt comes up every time I start X-LibreOffice if I haven't installed it. I don't want it since Java is not required by LibreOffice and the only functions that require it, I don't need (document creation wizards, database, etc). But X-LibreOffice prompts me every time to download it and there's no option to tell it to knock if off when I cancel. I was going to look into why it works this way, but it doesn't seem like the Java Get source code is available, despite the binary being hosted on SourceForge. I didn't see it anywhere in the X-LibreOffice package nor anywhere in your Sources directory on SourceForge which seems to be missing a lot of sources.

Additionally, it seems Java Get and the WinPenPack website are using the Java trademark in violation of Oracle's trademark guidelines without their express consent. This should be remedied as the current implementation is a violation of trademark law. The Java name and Java logo are not to be used in the names or icons of applications like Java Get. The logo can't even be used in association with them on the webpage. That's the reason our implementation is using our Oracle-approved trademark name, jPortable, and our own specialized icon and branding.

Finally, it seems you aren't hosting the complete source files for every version of LibreOffice you distribute as required by the GPL. This has been an ongoing issue with WinPenPack and should be remedied.

[SYSTEM]

Warning: offtopic.

That's the reason our implementation is using our Oracle-approved trademark name, jPortable, and our own specialized icon and branding.

Oh, I hadn't realized that that picture is an icon.

I've replaced the icon in the jPortable entry. (I created the 32*32 icon by simply downscaling the 128*128 one. Feel free to replace it with a higher-quality icon if you have one.)

[JohnTHaller]

I've replaced the icon in the jPortable entry. (I created the 32*32 icon by simply downscaling the 128*128 one. Feel free to replace it with a higher-quality icon if you have one.)

I smoothed it out a bit and put in a new version, well the best you can do with an old-school GIF anyway. I hadn't looked at the entry for jPortable on PFC, so I didn't know it wasn't using the proper icon.

[webfork]

Additionally, it seems Java Get and the WinPenPack website are using the Java trademark in violation of Oracle's trademark guidelines without their express consent. ... It seems you aren't hosting the complete source files for every version of LibreOffice you distribute as required by the GPL. This has been an ongoing issue with WinPenPack and should be remedied.

In terms of the letter of the law, you're absolutely right, but in terms of this having any actual consequence, I really don't see it:

• Its very unlikely that Free Software Foundation will even address their GPL violation, much less issue some kind of cease and desist. Their focus is on community and there's a long standing truth in legal matters that you don't sue people you like (or want to like you). In other words, the WPP project isn't likely to go offline as a result of violating the GPL.
• Its similarly unlikely that Oracle will take action either: they are driven by the bottom line, and WPP doesn't exactly have deep pockets. Unless a current Oracle litigation target like Google points to projects like WinPenPack as examples why they're not in the wrong, there's really no danger JavaGet projects on WPP will go offline either.

There is a difference, however: if the FSF actually did take action, its relatively easy to resolve by just posting the source code. Based on their previous behavior, Oracle meanwhile is likely to do it scorched-earth style: they will say no and give us $$$.

Note that if the WPP project starts seeing really huge activity or some serious donations and monetary gain, this would look a lot different. Their status as a small, niche project is probably all the protection they need.

That said, I do think its unfair to use GPL code and not follow the license the way the developers asked. Its part of why I discontinued my own software distribution project. I hope the WPP project will start hosting source code -- not because its likely to see some kind of legal rebuke -- but because its the right thing to do.

[webfork]

With the recent LibreOffice Portable 3.4.3 and 3.3.4 releases, PortableApps.com has added the ability for LibreOffice Portable to be able to run form a path with spaces

I forgot to mention: this is good news. Although they're not yet radically different in features, I prefer LibreOffice and have been waiting for something like this to switch over.

[ZioZione]

Hi JohnTHaller,

Hi John, it's nice to know that! Finally also LibreOffice Portable has implemented this feature but, I want to remember you all, the "X-Versions" are downloadable since

Ah, I see I was mistaken. Sorry about that. The last time Danix had said spaces were supported, X-LibreOffice simply crashed hard in LibreOffice itself (no friendly warning like LibreOffice Portable) since spaces were still an issue. It seems that spaces seem to be working now. I must have tested a previous version by accident.

spaces in the path have never been an issue in X-LibreOffice, but the problem is caused by Windows that does not support too long paths (with or without spaces) http://www.winpenpack.com/en/e107_plugi ... 0.cat.8.37 . The (surely user-friendly) warning of LibreOffice Portable was a simple placeholder waiting for the patch, because, until now, it doesn't supported spaces in the path.

Unfortunately, X-LibreOffice is using a buggy implementation, so while spaces now work, X-LibreOffice has other issues. For instance, sometimes when I alter the directory path, X-LibreOffice crashes out on launch without error and needs to be started a second time, while LibreOffice Portable with our spaces patch continues working with the same path changes. (From X:\PortableApps\LibreOffice to X:\PortableApps\Libre$Office for example). As you're using encoding on the path but only encoding a space to a %20 without encoding any other characters, this could be part of the issue. We're not using encoding on that same bootsrtap path and instead using a relative path that will not contain that special character, so that could very well be it.

On a related note, the $ is a special character in LibreOffice and X-LibreOffice isn't handling it properly. When run in the above example, X-LibreOffice creates an additional X:\PortableApps\Libre directory and stores some things in it. LibreOffice Portable with our spaces patch correctly handles the $ character. Again, I'd wager this is related to your partial implementation of encoding.

This seems more a LibreOffice bug (related with the coding of the characters into bootstrap.ini file), because if you try to put "$" in the path of any other X-Software, it continue to work correctly. Anyway, yesterday evening I have fixed this behavior in X-LibreOffice launcher, that will be available soon. In this way, bootstrap.ini file will continue to have absolute paths, that I think are more readable...

I noticed some additional issues in testing, so you're aware of them. First off, there seems to be no option at all to keep more than one language, which is a bit user-unfriendly and something that I know several users of LibreOffice Portable enjoy. You're stuck with English and one other language with no option at all to retain multiple languages the way LibreOffice Portable can. This isn't made clear at all by the first-run screen you're presenting to users. Especially since I couldn't see a way to get that initial screen to come up in a language other than English and the defaults include English-only. If I try to cancel that screen (natural instinct for a screen that's not understandable), I get an "Installation cancelled by user" error, then a prompt to install Java (which I also cancel), then LibreOffice tries to start and crashes, then I get the language selection screen AGAIN, which I cancel, then I get prompted to install Java again, which I cancel, then finally LibreOffice starts. As first run behavior goes, that's quite user-unfriendly.

First of all, you should keep well in mind that X-LibreOffice contains ALL available languages (as depicted also in our download page http://www.winpenpack.com/en/download.php?view.1323 ) and what you are saying could be related only to the X-LibreOffice first run installer. The messages are, in fact, a bit cryptic (it is just a first release) and could be surely modified to be more user-friendly. Anyway, all the additional languages/dictionaries can be added by the users later, modifying one parameter in the installer .ini and running again the installer; of course, also this job can be (and will be) make more user-friendly in the future.

As concerns Java, the Java Get prompt comes up every time I start X-LibreOffice if I haven't installed it. I don't want it since Java is not required by LibreOffice and the only functions that require it, I don't need (document creation wizards, database, etc). But X-LibreOffice prompts me every time to download it and there's no option to tell it to knock if off when I cancel.

This behavior is not from JavaGet but from the X-LibreOffice launcher itself, that wants be always sure to allow to the user to work with X-LibreOffice in its entirety. If this bother you, you can simply edit X-LibreOffice.ini file and comment (prefixing it with a semicolon char) the row containing the string "JavaGet", so the X-LibreOffice launcher does not search for Java anymore...

Best Regards
ZioZione
P.S. To forum admin: if you think that this topic is going OT, I agree with you...

[JohnTHaller]

spaces in the path have never been an issue in X-LibreOffice, but the problem is caused by Windows that does not support too long paths (with or without spaces) http://www.winpenpack.com/en/e107_plugi ... 0.cat.8.37 . The (surely user-friendly) warning of LibreOffice Portable was a simple placeholder waiting for the patch, because, until now, it doesn't supported spaces in the path

Hmm... I recall running X-OpenOffice.org crashing from a short path with a space (X:\Open Office) previously and I even recall Danix admitting it in a forum post here a while back. I think this was due to its internal handling of the path (OO.o, not X-OO.o) with a space in a location other than bootstrap.ini. I also remember investigating use of simple URL encoding on the path in bootstrap.ini and discovering that it broke something else somewhere at the time which is the whole reason we built in the ability for the launcher to show the friendly error when running from a path with a space instead of just handling it. I could be mistaken, though, and I apologize if I am.

This seems more a LibreOffice bug (related with the coding of the characters into bootstrap.ini file), because if you try to put "$" in the path of any other X-Software, it continue to work correctly. Anyway, yesterday evening I have fixed this behavior in X-LibreOffice launcher, that will be available soon. In this way, bootstrap.ini file will continue to have absolute paths, that I think are more readable...

It's not a LibreOffice bug, it's the way it handles the $ character (treating it and the following characters as an environment variable). So, it is a bug in the X-LibreOffice and X-OpenOffice.org launchers. I'm glad you'll be fixing it based on my suggestion by encoding it to %24. I'd highly suggest doing this with other special characters so you don't find another one that isn't handled.

First of all, you should keep well in mind that X-LibreOffice contains ALL available languages (as depicted also in our download page http://www.winpenpack.com/en/download.php?view.1323 ) and what you are saying could be related only to the X-LibreOffice first run installer. The messages are, in fact, a bit cryptic (it is just a first release) and could be surely modified to be more user-friendly. Anyway, all the additional languages/dictionaries can be added by the users later, modifying one parameter in the installer .ini and running again the installer; of course, also this job can be (and will be) make more user-friendly in the future.

It doesn't matter if it includes all languages (zipped up and unavailable to LibreOffice) if the user is forced to delete them on first-run without warning. I doubt anyone would understand this from the screen you present.

This behavior is not from JavaGet but from the X-LibreOffice launcher itself, that wants be always sure to allow to the user to work with X-LibreOffice in its entirety. If this bother you, you can simply edit X-LibreOffice.ini file and comment (prefixing it with a semicolon char) the row containing the string "JavaGet", so the X-LibreOffice launcher does not search for Java anymore...

That's a bit user-unfriendly way to fix things. Especially since the user preference will be reset on every upgrade (the same issue with disabling splash screens being reset back to enabled when upgrading WinPenPack software which users have complained about here as well).

Also, since you're reading this, please remedy WinPenPack's GPL violation by hosting the source code for every version of LibreOffice (you're not redistributing sources for any of them at present) and every version of the other GPL apps you distribute as well as releasing the source code for Java Get as required by the SourceForge.net terms of service.

[Hydaral]

Also, since you're reading this, please remedy WinPenPack's GPL violation by hosting the source code for every version of LibreOffice (you're not redistributing sources for any of them at present) and every version of the other GPL apps you distribute as well as releasing the source code for Java Get as required by the SourceForge.net terms of service.

Does the GPL actually require them to host the sources? I though anyone distributing the binaries was only obligated to provide the source when requested or provide a link to where it can be found.

[JohnTHaller]

Does the GPL actually require them to host the sources? I though anyone distributing the binaries was only obligated to provide the source when requested or provide a link to where it can be found.

It's well known and well established. It's even been discussed here more than once. It's a part of the GPL to ensure the source is always available and that everyone distributing the binary also does their fair share of work distributing the source (bandwidth, uploading, explaining, etc). It's also to prevent a smaller project by being overwhelmed by a larger project distributing the binaries and having to distribute the source to all those other users and ensure the source is available from the project that redistributes in case the original goes away. In other words, it's about fairness and continuity. The FSF themselves mention it right here: http://www.gnu.org/licenses/gpl-faq.htm ... JustBinary

[Danix]

but it doesn't seem like the Java Get source code is available, despite the binary being hosted on SourceForge.

Please, take the time to search in our repository before making a false statement! The JavaGet code is on SVN since 21 months, you have just to search it. As well as all our code, as I have said many times. Since someone does not want to understand this, I repeat again. So, please, stop to denigrate winPenPack with false statements. Your constant annotations on our license start to get boring.

That said, I do think its unfair to use GPL code and not follow the license the way the developers asked. Its part of why I discontinued my own software distribution project. I hope the WPP project will start hosting source code -- not because its likely to see some kind of legal rebuke -- but because its the right thing to do.

There is nothing to hope, webfork, because we already host our source code, as I said above. About the code of programs associated with X-Software please follow the link below. Our project is based upon the maximum observance of both the licenses and the authors will so we cannot accept any criticism that we are not working in a sphere of legality, because "the legality anyhow" has been always the first assumption of all our work.

Finally, it seems you aren't hosting the complete source files for every version of LibreOffice you distribute as required by the GPL. This has been an ongoing issue with WinPenPack and should be remedied.

"If you make object code available on a network server, you have to provide the Corresponding Source on a network server as well. The easiest way to do this [ie to provide the object code and the Corresponding Source] would be to publish them on the same server, but if you'd like, you can alternatively provide instructions for getting the source from another server, or even a version control system. No matter what you do, the source should be just as easy to access as the object code, though. This is all specified in section 6(d) of GPLv3." (http://www.gnu.org/licenses/gpl-faq.htm ... endSources)

Section 6.d of GPLv3: "If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements."

As I have said here http://www.portablefreeware.com/forums/ ... 1ed#p33290 and I hope sincerely it's the last time, I think what matters is to give access to the source code, on the same or another server or even through CVS or SVN. Among other things, the source code we are talking about, belongs to programs associated with the launchers for creating portable versions. Programs are included in portable versions in unmodified form, at least in winPenPack's portable software. So, I think it is unnecessary to provide the unmodified source code belonging to a program developed by others, especially if this code is already present on the same server (although every time we however add sources on SourceForge).

Also, since you're reading this, please remedy WinPenPack's GPL violation by hosting the source code for every version of LibreOffice (you're not redistributing sources for any of them at present) and every version of the other GPL apps you distribute as well as releasing the source code for Java Get as required by the SourceForge.net terms of service.

Does the GPL actually require them to host the sources? I though anyone distributing the binaries was only obligated to provide the source when requested or provide a link to where it can be found.

Obviously I agree with this.

Additionally, it seems Java Get and the WinPenPack website are using the Java trademark in violation of Oracle's trademark guidelines without their express consent. This should be remedied as the current implementation is a violation of trademark law. The Java name and Java logo are not to be used in the names or icons of applications like Java Get. The logo can't even be used in association with them on the webpage. That's the reason our implementation is using our Oracle-approved trademark name, jPortable, and our own specialized icon and branding.

I don't think we are violating something because we don't distribute Java. JavaGet IS NOT Java, JavaGet DOES NOT CONTAIN Java. The only task of JavaGet is to download and install Java in the correct directory. Is about the same thing that PA does for Chrome Portable.

[JohnTHaller]

but it doesn't seem like the Java Get source code is available, despite the binary being hosted on SourceForge.

Please, take the time to search in our repository before making a false statement! The JavaGet code is on SVN since 21 months, you have just to search it. As well as all our code, as I have said many times. Since someone does not want to understand this, I repeat again. So, please, stop to denigrate winPenPack with false statements. Your constant annotations on our license start to get boring.

I'm not sure why you find the need to twist my statement like that to try and create drama again. I clearly said "doesn't seem" as when I checked I found no reference to the JavaGet sourcecode on the X-LibreOffice download page nor in the X-LibreOffice readme included about where to obtain the source code other than WinPenPack's website and project and I did not see any reference to it there. Generally, you should link directly to the source code download or directory it is in or the proper section of SVN from each app's page to avoid people hunting around trying to locate the source code. The FSF itself says you should provide clear directions on the same page you download the binary from. There is no reference to the JavaGet source anywhere on the X-LibreOffice page nor in the included documentation.

After hunting around, I finally found it through blind luck. From the X-LibreOffice page, I had to click on "Launcher Sources" even though it's not a launcher. From there, you select from "branches", "tags" and "trunk". You need to click "trunk" as there doesn't appear to be a 'stable' branch (which I found only after exploring the other two). From there, you select from utility, wpp-menu, wpp-menu_svn, x-launcher, x-software... you select "utility" (which I found only after exploring x-launcher since I did click on Launcher Sources earlier so I assumed you called it a launcher). Only then do you see the first reference to JavaGet. I honestly wouldn't consider that to be a clearly described way to find the source. So you should understand why I said "it doesn't seem like the Java Get source code is available". It's very difficult to find. And there is no search facility available for your repository on the page.

So, yes, the JavaGet source code is available, so I was incorrect when I said it didn't seem like it was. I'd appreciate an apology for calling me a liar simply because I couldn't find something buried in multiple sub-directories and merely pointing out that it didn't seem like it was available because I couldn't find it. There was no reason to respond as harshly as you did to a statement like that.

There is nothing to hope, webfork, because we already host our source code, as I said above. About the code of programs associated with X-Software please follow the link below. Our project is based upon the maximum observance of both the licenses and the authors will so we cannot accept any criticism that we are not working in a sphere of legality, because "the legality anyhow" has been always the first assumption of all our work.

He's referring to the fact that you refuse to host the source for all binaries you distribute as required by the GPL.

"If you make object code available on a network server, you have to provide the Corresponding Source on a network server as well. The easiest way to do this [ie to provide the object code and the Corresponding Source] would be to publish them on the same server, but if you'd like, you can alternatively provide instructions for getting the source from another server, or even a version control system. No matter what you do, the source should be just as easy to access as the object code, though. This is all specified in section 6(d) of GPLv3." (http://www.gnu.org/licenses/gpl-faq.htm ... endSources)

Section 6.d of GPLv3: "If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements."

As I have said here http://www.portablefreeware.com/forums/ ... 1ed#p33290 and I hope sincerely it's the last time, I think what matters is to give access to the source code, on the same or another server or even through CVS or SVN. Among other things, the source code we are talking about, belongs to programs associated with the launchers for creating portable versions. Programs are included in portable versions in unmodified form, at least in winPenPack's portable software. So, I think it is unnecessary to provide the unmodified source code belonging to a program developed by others, especially if this code is already present on the same server (although every time we however add sources on SourceForge).

You can continue to remain willfully ignorant of the FSF's actual directives as many times as you would like, despite me linking to the related FAQs, but the fact remains you are required to host the sources for LibreOffice as you are redistributing the binaries. The FSF say it quite clearly in the FAQ I linked to. Both servers must be under your control. Even though PortableApps.com hosts the source code on our project on SourceForge for all the apps you distribute, you must host them as well in your own project as ours are not under your control and could be removed, putting you in violation. If you'd like, I can have SourceForge.net or some of the publishers contact you directly to reaffirm this.

I don't think we are violating something because we don't distribute Java. JavaGet IS NOT Java, JavaGet DOES NOT CONTAIN Java. The only task of JavaGet is to download and install Java in the correct directory.

The Java name and logo are simply not available for using JavaGet. Oracle says so quite clearly in their trademark guidelines. I spoke with Oracle's lead counsel directly on this and even though Java Portable didn't contain the JRE, we were not allowed to use the Java name as part of the product. The Java logo is even more restricted as it doesn't permit use in any manner except very specific guidelines in relation to Java software and devices they have approved, neither of which apply to JavaGet. Using it as a program icon is a direct violation.

Please consider the fact that I'm merely pointing out the facts and violations as I see them (and they have been described to me directly by Oracle, SourceForge.net and a representative of the FSF) and respond in kind before trying to call me out as a liar again. We don't need that kind of drama here. I'm simply asking you to observe the same rules and guidelines that you agreed to by redistributing GPLed software and that PortableApps.com and I follow quite willingly.

[zandet2]

It's very difficult to find. And there is no search facility available for your repository on the page.

Don't tell to us, please send your grievance to SourceForge, the owner of the repository.

Best regards
zandet2

[zandet2]

I'd appreciate an apology for calling me a liar ...

and respond in kind before trying to call me out as a liar again.

No one call you "liar" since now, so do not accuse anyone please.

Best regards again
zandet2