The odt file is a compressed zip archive. Compressing the contained
pictures would hardly reduce the file size.
The odt file is a compressed zip archive. Compressing the contained
pictures would hardly reduce the file size.
That's not true. The point was (if I remember this thread correctly) that
when designing the document, you have high-definition pictures, say
1200dpi, and those takes a lot of space. Now, if you want to output this
for a projector you'll only need pictures at 90dpi, or for printing with a
medium quality you only need 150dpi, and doing a poster you'll need the
whole 1200dpi.
Sending the same file with the original 1200dpi pictures to everyone sure
is a solution, but you'll see the waste of space. It doesn't have anything
to do with odt file being compressed; there's juste *more* informations
with bigger images. Other (impractical) solutions could be to maintain
multiple version of the same file, or keep the images linked to multiple
folder, and swap them outside of LibreOffice. Not good when you manipulate
large documents.
Now, what would be nice is a way to take an odt with such large pictures,
and produce different versions suited for different needs. You keep the
"original", and with the press of a button, produce a separate odt file
where the pictures are scaled down appropriately (like the option in PDF
export). From the discussion, it looks like MS Word have something like
this, and while mimicking Word is not a necessity, I clearly see the need
for such an option for LibreOffice power users.
Cley seems to have created something like an Extension or maybe
independent program to automatically re-scale the byte-size of all images
in a document and i'd forgotten all about it.
It was (is? I probably left it online) a separate tool. You could feed it
an ODT, and produce a (hopefully) smaller ODT where all pictures are scaled
to a given dpi.
It was only a proof of concept: I didn't read the whole ODT spec or
something. It works by looking in the XML for pictures links, and retrieve
their "printing" size (in centimeters). It then scale down all linked
images in the ODT archive, so that their size in pixels exactly meet their
printing size for the specified DPI.
For example, if you have a document with a picture set to 10x10cm, and the
picture source is 4700x4700 pixels, the image is roughly at 1200dpi. When
modified for printing at 150dpi, the picture would be scaled back to
590x590 pixels, drastically reducing the file size while keeping the
expected output quality.
(this also depend on scaling methods and other things, but it was the
general idea).
Hi.
There is a 10 MB file size limit, which my book exceeds due to the
included pictures.Thomas, beginning with LibreOffice 4.1 there is a new feature where if
you right-click on an image in your document you will see the option
"Compress Graphic...".This opens a dialogue box where you are provided with information about
that image (including its current size), proposed compression settings,
and a Calculate button to see the new size of that image if you were to
accept those settings.I have not found a way to do this on all the images at once.
Because the changes are permanent, I suggest you *first* save a copy of
the original (large) document. That way you can try again if you
compress the images too much and loose too much image quality.Dale.
I just found a bug in my 4.1.6 using this. If I compress (resize) any
images by this method I start to get read-error for other images and
they are lost from the document.
Steve
Hi
Errr, i think i don't understand Git Hub.
I thought it was only for writing code and although it made it easier to
collaborate with other people it was 'just' about writing code. I didn't
thing it was for releasing code to "the general public". Now i'm beginning
to think that view might have been too limited and out-dated.
Is it easy to get some sort of equivalent to a YouTube "channel" to help to
collect together tools (such as this one) that are relevant to
LibreOffice? Maybe some sort of tags or labels so that channels for
Caligra, Gnome Office and others can share tools without having to
duplicate the tools?
Also GitHub looks a lot more elegant and professional than i expected. I
was expecting it to look bad but have tons of power "under the bonnet".
Regards from
Tom
Hi
I know it was only an alpha-release but it fits the idea of "release early
and release often" rather than trying to produce something too perfect and
then finding that no-one uses it.
If it's possible to get it onto the Extensions website
http://extensions.libreoffice.org/
then maybe more people could attempt to use it and maybe post bug-reports,
and maybe even help develop it further (Gpl, LGpl. Mpl or whatever
copy-left license seems best (ideally same as other Extensions use)).
I guess i can imagine a few finesses that probably wouldn't even be useful
to most people. So, feedback and comments would become useful. The
Extensions website seems set-up to handle that sort of thing.
Errr, zipped images are often not hugely smaller than their original size.
The advantage is that the zip-file ends up being a container holding all
the different bits together. Scaling reduces image's byte-size far more.
Regards from
Tom
Hi
I really like the sound of this!
Cley seems to have created something like an Extension or maybe independent
program to automatically re-scale the byte-size of all images in a document
and i'd forgotten all about it.
I've only known 1 person to create a really hefty document by just plonking
in unedited photos. Generally i edit images to at least scale them
suitably before plonking them in but such faffing around is beyond the ken
of most normal users, of course.
Is it possible to put this on the LO Extensions site? Even if it's an
independent program it'd still be useful to have it easier to find imo.
Regards from
Tom
Hi
Wow!! Please can you post a bug-report about this!
There is a collection of quite ancient but extremely rare bugs that have
this effect. It has been a nightmare trying to get conditions exactly
'right' to make any of these bugs appear in any consistent way. It's like
chasing phantoms in heavy fog, at night. Problem is that there's more than
1 phantom so when trying to chase down one another skips across your path
distracting you and allowing both to escape. If one example of the bug can
be reproduced reliably then it tends to be fairly easy for the devs to find
and fix it.
The problem is that even something simple like closing and reopening LO or
rebooting the machine often chases the bug away for a while. A couple of
years ago the Docs Team managed to trick one of the bugs out into the open
so that a given set of conditions was guaranteed to produce the bug. The
devs then fixed it within days. Since then only 1 phantom appeared and
that was about a year ago and it managed to escape back into the fog.
At one point the Docs Team started to try to keep copies of all
screen-shots in a separate folder so that when the images magically all
vanished it was fairly easy to replace them. Sadly even older copies and
back-ups of an affected file seemed to magically lose images.
Also there were attempts to rename the file-ending from ".odt" to ".zip"
but the images folder in there was also mysteriously empty, even in the
older or back-up versions!
So, if you CAN reliably re-create a set of conditions where images have the
"read error" then pleeeeease post a bug-report!
Regards from
Tom
Just an FYI. I'm using GitHub for info on some computer hardware and will be adding a repository for SQLite query code for my LambTracker program that is a separate repository there. In fact am looking at either a link to Scrivener files or ODT files for my query info. I
There are many GitHub project that are not code at all.
Some of the private repositories use GitHub to manage huge document collections as in laws and things for various government entities.
The thing GitHub does not seem to handle well is when the item that has the changes is an image. How to keep changes to graphics is not an easy problem. You can save the entire new picture file but a better way would be to save the changes only. Not easy though.
Errr, i think i don't understand Git Hub.
I thought it was only for writing code and although it made it easier to
collaborate with other people it was 'just' about writing code. I didn't
thing it was for releasing code to "the general public". Now i'm beginning
to think that view might have been too limited and out-dated.
Eugenie (Oogie) McGuire
Desert Weyr, LLC - Black Welsh Mountain Sheep http://www.desertweyr.com/
LambTracker - Open Source SW for Shepherds http://www.lambtracker.com
Paonia, CO USA