thanks for pointing it out. i'd have mentioned that i dropped the earlier packages here, but as of about three months ago, every file i've dropped from my repo for tidying purposes has been accompanied by a message telling me that it's still shared on other users' drives. i checked a few times and found the links to files i deleted invariably worked. seeing that's no longer the case, i guess others are doing some fall pruning as well. anyway, i read you can run the 4.2 series and 4.3 series at the same time on the same computer, which the makers of LO may have pointed out with this release because it is something new. i've never tried it, but it's a conceivably useful feature.Griot wrote:Didn't know that, thanx for sharing.
LibreOffice + language packs (latest version: 6.1.4)
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
LibreOffice-4.3.2_en-US_xz.sfs (178mb) and LibreOffice-4.3.2_en-US_xz.pet (214mb)
I updated the links. Dogfellow's packages are now on the first page. There's also an updated SFS of libreoffice including Spanish language. The link to French libreoffice is to the ASRI Éducation forum which will likely update its version including French language soon. For more languages, users can install one of the langpacks from the first page, or request a langpack if there isn't a package of their language yet.
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
Also Java SFS updated to 1.7u67 thanks to Shinobar.
http://shino.pos.to/party/bridge.cgi?pu ... 7.0.67.sfs
http://shino.pos.to/party/bridge.cgi?pu ... 7.0.67.sfs
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
vicmz wrote:Also Java SFS updated to 1.7u67 thanks to Shinobar.
http://shino.pos.to/party/bridge.cgi?pu ... 7.0.67.sfs
maybe of interest to some: the sfs i offered and used to make the pet was made with shinobar's tweaked version of 01micko's get_libreoffice script. both packages should be somewhat smaller than they would otherwise have been.
Pretty much shipshape and, of course, car-shaped;
and whilst cross-threaded:
* Ted Dog's "ram2sfs" handled StartMount correctly, yet he (like the rest of us) had never heard of SFS-Remastering-Suite, let alone its requirements.
* I wrote I had workarounds - so my remaster is more automated - the only preparation being to delete any "loadings" in my task bar.
and whilst cross-threaded:
To be "pouring blood" obvious:" it failed to deal correctly with StartMount from 01micko.." because 01micko's StartMount was not written with SFS-Remastering-Suite's requirements in mind! You could request 01micko to modify his script accordingly!
* Ted Dog's "ram2sfs" handled StartMount correctly, yet he (like the rest of us) had never heard of SFS-Remastering-Suite, let alone its requirements.
* I wrote I had workarounds - so my remaster is more automated - the only preparation being to delete any "loadings" in my task bar.
LibreOffice
Interesting. I built my SFS using 01micko's get-libreoffice 0.30 and got the same file size. Then I thought SFR's tools could further reduce my 178 MB SFS, so I extracted the file with UExtract and repackaged the content as xz-compressed SFS (default compression level) with the Pack it! compression utility. I tested the new file, it works OK.Puppus Dogfellow wrote:maybe of interest to some: the sfs i offered and used to make the pet was made with shinobar's tweaked version of 01micko's get_libreoffice script. both packages should be somewhat smaller than they would otherwise have been.
It may seem no big deal, but by doing this I managed to get a 161 MB SFS of LibreOffice, with the addition of Spanish translations and help files. Maybe the fact that I used an NTFS partition to download and build, and then a Linux partition to rebuild, has something to do.
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
compression, decompression, Post Depression
i think the savings with shinobar's tweak comes from a reduced icon cache in the pupsave--it eliminates any icons over 128x128, none of which i can remember having come across, so it didn't seem like it'd hurt to try it out. 161 is a nice size--i don't think even the late three series ever got that small. fwiw, i always download to an ext4 partition--i may have a few vfats around somewhere, but nearly all my partitions are linux partitions. any idea what size pet your sfs would convert into? xz is default compression with the Pack It! utility and gz's the default with the get_libreoffice utility and that's where the difference comes from? if so, is there any advantage to the gz-compressed file?vicmz wrote:Interesting. I built my SFS using 01micko's get-libreoffice 0.30 and got the same file size. Then I thought SFR's tools could further reduce my 178 MB SFS, so I extracted the file with UExtract and repackaged the content as xz-compressed SFS (default compression level) with the Pack it! compression utility. I tested the new file, it works OK.Puppus Dogfellow wrote:maybe of interest to some: the sfs i offered and used to make the pet was made with shinobar's tweaked version of 01micko's get_libreoffice script. both packages should be somewhat smaller than they would otherwise have been.
It may seem no big deal, but by doing this I managed to get a 161 MB SFS of LibreOffice, with the addition of Spanish translations and help files. Maybe the fact that I used an NTFS partition to download and build, and then a Linux partition to rebuild, has something to do.
well, were it both shipshape and ship-shaped, i think it'd've maybe been more a Citroen than a Morris.Jasper wrote:Pretty much shipshape and, of course, car-shaped;
still, seems like quite a good deal you got. don't know much about the marque, but that '37'd probably go for a good deal more these days, no?
they look like they'd make cool hot rods.
Re: compression, decompression, Post Depression
Pack it! is a compression utiliy supporting multiple compression formats. As far as I know get-libreoffice uses xz compression, too. Maybe there's a difference in the code of both utilities. Regarding gz compression, it's bigger, but it's said to run faster and be the best for old hardware - the older the hardware is, the more recommended. I never cared about making gz-compressed LibreOffice files because LibreOffice itself is a really big suite for an old machine (Abiword and SoftMaker would run much faster in those machines).Puppus Dogfellow wrote:i think the savings with shinobar's tweak comes from a reduced icon cache in the pupsave--it eliminates any icons over 128x128, none of which i can remember having come across, so it didn't seem like it'd hurt to try it out. 161 is a nice size--i don't think even the late three series ever got that small. fwiw, i always download to an ext4 partition--i may have a few vfats around somewhere, but nearly all my partitions are linux partitions. any idea what size pet your sfs would convert into? xz is default compression with the Pack It! utility and gz's the default with the get_libreoffice utility and that's where the difference comes from? if so, is there any advantage to the gz-compressed file?
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
Re: compression, decompression, Post Depression
And OOo4kids is faster too, not only for kidsvicmz wrote:LibreOffice itself is a really big suite for an old machine (Abiword and SoftMaker would run much faster in those machines)
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
Re: compression, decompression, Post Depression
the size difference in the two sfs files seems somewhat consistent with the difference in gz vs xz compression, though a quick read through the get_libreoffice thread revealed that the script will use xz if the machine is capable of it. the precise i used to build it is, though i can vaguely remember a .gz file being created at some point in the build. since i don't trust my memory of the fleeting processes, is there a way i can check what compression is being used for my sfs? if gz, i'd keep it for the speed and marginally better compatibility. if xz, your method seems preferable. i'm not sure if it's still the case, but wary was described as unable to use xz.vicmz wrote:Pack it! is a compression utiliy supporting multiple compression formats. As far as I know get-libreoffice uses xz compression, too. Maybe there's a difference in the code of both utilities. Regarding gz compression, it's bigger, but it's said to run faster and be the best for old hardware - the older the hardware is, the more recommended. I never cared about making gz-compressed LibreOffice files because LibreOffice itself is a really big suite for an old machine (Abiword and SoftMaker would run much faster in those machines).Puppus Dogfellow wrote:i think the savings with shinobar's tweak comes from a reduced icon cache in the pupsave--it eliminates any icons over 128x128, none of which i can remember having come across, so it didn't seem like it'd hurt to try it out. 161 is a nice size--i don't think even the late three series ever got that small. fwiw, i always download to an ext4 partition--i may have a few vfats around somewhere, but nearly all my partitions are linux partitions. any idea what size pet your sfs would convert into? xz is default compression with the Pack It! utility and gz's the default with the get_libreoffice utility and that's where the difference comes from? if so, is there any advantage to the gz-compressed file?
abi and softmaker have been relatively buggy for me, and libre works well enough on my one gig machine. haven't tested it on anything with less.
am i wrong in thinking the difference between the two compression methods comes down to a choice between a space savings on the disk versus a time savings upon decompression? once it's loaded, it's pretty fast regardless, though it by no means opens as instantly as abi.
agreed. it loads faster and appears to work very well.boxR wrote:And OOo4kids is faster too, not only for kidsvicmz wrote:LibreOffice itself is a really big suite for an old machine (Abiword and SoftMaker would run much faster in those machines)
Yeah, there's the all-purpose OOoLight, too. I tested sometime ago and managed to make a 76 MB SFS. The only thing I didn't like (see screenshot below) is that GTK scrollbars and buttons don't look like they should (I wonder why).boxR wrote:OOo4kids is faster too, not only for kids
I also tested Apache OpenOffice, the SFS I made of version 4.1.1 was 139 MB, gz-compressed. Of course LibreOffice is more developed, and Apache OpenOffice can open docx but not save to docx, but if you don't mind these details and if your hardware is old Apache OpenOffice can be a good alternative.
I don't know. Maybe if you ask in the get-libreoffice thread (see the link at the beginning of the first post). I used SFR's tools as a way of forcing xz compression, just out of curiousity, to see what happened. I didn't expect to get a significant difference in size.Puppus Dogfellow wrote:is there a way i can check what compression is being used for my sfs?
- Attachments
-
- ooolight.png
- (64.03 KiB) Downloaded 330 times
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
Re: primary selection problem in 4.3.0
i'm no longer convinced this problem was libreoffice related. the problem disappeared (in precise 5.5, 5.6.1, 5.7.1) after upgrading parcellite .9_ with Médor's parcellite-1.1.8-precise.pet. it's possible this fixed a conflict between glipper and the older parcellite. regardless, it's more capable and configurable than either, and recommended.Puppus Dogfellow wrote:has anyone else noticed a problem with the middle click copy/paste in 4.3.0?
on all three of my machines--precise 5.5, 5.6, 5.7--the selection doesn't get fully copied or gets copied in some mangled manner or it doesn't register at all. the function works fine in all my other programs and the ctrl+c/ctrl+v works perfectly fine in libre, but this is definitely buggy from where i sit, so i personally recommend 4.2.5 for now. anyway, figured i should report this. the file is my own generated from 01micko's program. the pet conversion is similarly afflicted. not sure how slacko variants fared with it.
reboots didn't fix it, changing the parcelite and glipper settings didn't fix it, and making sure it was set to recognize middle click behavior in tools>options>view didn't fix it (that part was okay to begin with).
update:
it appears the behavior might be related to a 4.3 fix for the inability of 4.2 to easily transfer text between the main document and the comments (i used to have to copy it to leafpad or similar to get it from the the comments into the body...don't remember if pasting into the comments was also a problem...). now you can paste into the comments with ctrl+v and paste from the comments into the body with either ctrl+v or a middle click. middle clicking to paste in the main of the document doesn't work, but in the comments you get use of both the middle click paste and the ctrl+v/context menu paste and can use either to place text into the document. middle click (in addition to ctrl+v/right click paste) can also be used to paste text from other sources into a writer document--it's only useless when it comes to grabbing text on the actual pages of a writer document: it will wipe out what's stored there if you do and you will only be able to use ctrl+v/context menu paste until a selection sourced from elsewhere is made to fill the void created when libreoffice writer 4.3 tried to middle-click select its own text.
guess i'll stick with the 4.3 series after all...
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
Vicmz & Puppus:
I use scripts with Libre in the background to convert between formats. Do you know if the JRE (Java) is required for this? Specifically, I'm converting .rtf to .PDF and while my script shows errors messages pertaining to Java in the terminal, it seems like the PDF's are created properly.
Thanks for your thoughts.
Slavvo67
I use scripts with Libre in the background to convert between formats. Do you know if the JRE (Java) is required for this? Specifically, I'm converting .rtf to .PDF and while my script shows errors messages pertaining to Java in the terminal, it seems like the PDF's are created properly.
Thanks for your thoughts.
Slavvo67
It depends on the content of the documents. If they're simple documents, with pictures and tables at most, then Java shouldn't be necessary. You could experiment to see if there is any difference between converting with Java enabled or disabled. Also:slavvo67 wrote:Vicmz & Puppus:
I use scripts with Libre in the background to convert between formats. Do you know if the JRE (Java) is required for this? Specifically, I'm converting .rtf to .PDF and while my script shows errors messages pertaining to Java in the terminal, it seems like the PDF's are created properly.
Thanks for your thoughts.
Slavvo67
http://en.libreofficeforum.org/node/7170#comment-29223
oweng wrote:There is a list of the pieces of LO that use Java here. The main user experience pieces are probably (in no particular order):
Wizards. ---Rewriting of the fax/letter/agenda/web/report/form/table wizards in Python is now complete (FDO#38820).
Report Builder.
Report Designer. ---On closer analysis, Java components are QA only.
Script providers (BeanShell, Javascript).
Solver for Nonlinear Programming.
Wiki Publisher.
Some linguistic (l10n) functions. ---Merge filter (FCFGMerge) and utils replaced with Python equivalent (pyAltFCFGMerge).
Filter tool for splitting XML files into fragments.
Any entry in the linked list that contains “qa
[url=http://murga-linux.com/puppy/viewtopic.php?t=76948]Puppy Linux en español[/url]
Not sure if you guys noticed but apparently Libre is now producing a portable version.
http://www.libreoffice.org/download/portable-versions/
I haven't tried doing anything with them in puppy... at least yet.
http://www.libreoffice.org/download/portable-versions/
I haven't tried doing anything with them in puppy... at least yet.
- Puppus Dogfellow
- Posts: 1667
- Joined: Tue 08 Jan 2013, 01:39
- Location: nyc
Re: clipboards
there's a problem clearing the clipboard history with Médor's pet, at least on the precise 5._ machines i tried it on. parcellite_1.1.9-1_i386.deb works/installs correctly in 5.7._. i haven't tried it in 5.6.1, but it fails to fix the problem in 5.5.Puppus Dogfellow wrote:
i'm no longer convinced this problem was libreoffice related. the problem disappeared (in precise 5.5, 5.6.1, 5.7.1) after upgrading parcellite .9_ with Médor's parcellite-1.1.8-precise.pet. it's possible this fixed a conflict between glipper and the older parcellite. regardless, it's more capable and configurable than either, and recommended.