vicmz wrote:Also Java SFS updated to 1.7u67 thanks to Shinobar.
http://shino.pos.to/party/bridge.cgi?pu ... 7.0.67.sfs
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!
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.
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;
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?
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)
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?
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 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?
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...
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
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
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.
i got a 158 mb sfsof LO432_us_en plus help files using UExtract and radky's PArchive, which i don't remember installing (it may have been a part of don570's right click utilities--i'm pretty sure that's where i got UExtract from). i guess this is the way to go. if you're concerned with space, use the sfs; if you're concerned with load up speed, use the pet. then again, i'm not even sure load up speed suffers any. fwiw, i used micko's .30 rather than shinobar's .29.1 for this.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.
i doubt i'll ever use it. puppy is already pretty much a portable version.slavvo67 wrote: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.
I always use micko's, there's a link to his thread in the first post for those interested in creating LibreOffice sfs files.Puppus Dogfellow wrote: i got a 158 mb sfsof LO432_us_en plus help files using UExtract and radky's PArchive, which i don't remember installing (it may have been a part of don570's right click utilities--i'm pretty sure that's where i got UExtract from). i guess this is the way to go. if you're concerned with space, use the sfs; if you're concerned with load up speed, use the pet. then again, i'm not even sure load up speed suffers any. fwiw, i used micko's .30 rather than shinobar's .29.1 for this.
Actually, that's how I made my OB Precise iso (158 MB). First I rebuilt Precise 5.7.1 by Woof-CE master, then with the UExtract-PackIt combo made a remaster, this way I could put many updates not included in the original iso, plus leave Openbox as default. If I make an NOP-like iso (gray's Nearly Office Pups have Abiword, Gnumeric and InkScape removed) it'll be smaller. Yet smaller if I replace SeaMonkey with some lightweight browser, or with an install wizard featuring popular web browsers.Puppus Dogfellow wrote:i continued playing around with the technique and got a remaster of precise571 down from 154 to 140mb. thanks for the tip, vic. if someone reports a problem, i'll go back to the old way. in the meantime, if anyone wants to grab an abiwordless iso...
Not sure if you have noticed: Those are Windows versions.slavvo67 wrote: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.
is that because it includes what it needs from java or is the warning message just disabled? i tried it and it seemed to just launch my already installed libreoffice. does the thing autoupdate? i think it would be great if all software worked like that. why install if you don't have to...MochiMoppel wrote:Not sure if you have noticed: Those are Windows versions.slavvo67 wrote: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.
A slightly older portable version (LibreOffice 4.3.0.4) can be downloaded at PortableLinuxApps. While previous versions had nag screens ("Please install a JRE") or refused to run in Slacko, this version shows no problems (so far) in Slacko or Precise. Only 1 file. It starts surprisingly fast and I run it directly from a location outside of Puppy. Very nice!
Message is disabledPuppus Dogfellow wrote:is that because it includes what it needs from java or is the warning message just disabled?
More likely it used your existing profilei tried it and it seemed to just launch my already installed libreoffice
No, fortunately not. It's read-only - just like an sfsdoes the thing autoupdate?
From what I understand it works pretty much like a sfs, but with a much easier loading/unloading process (click to load, close app to unload) and without the version conflicts of a layered file system. If you read the interesting documentation you will realize that these apps are compressed images of ROX AppDirs, and when you copy the mounted folder that it creates in /tmp to a separate location you will end up with a veritable ROX AppDir. In theory it's easy to create your own images with the AppImageKit and there is also a video that describes the process, but I couldn't get it to work...i think it would be great if all software worked like that
