Containers, file size and references

#1

Hi all,

I'm trying to put files (pdfs and images) into my FM database, and I'm
studying various options.
I added a container field, and first I tried dragging a pdf file into
it. It worked, I could see the (reduced) image in FM, and
double-clicking it opened the pdf in Adobe Reader. All perfect so far,
except that the fp7 file size jumped from 88 KB to 11 MB!!! The pdf has
one A4 page, 48 KB, and it is the only file I tried to insert, into a
single record. After removing the file from the field and compacting
the database, it went back to 88 KB.
What is going on? Does FM store the file internally as an uncompressed
bitmap, or what? How can it be so awful?

The second thing I tried was inserting a file reference to the pdf. It
worked, and the database didn't increase in size, however the image was
not displayed (it showed a pdf icon and file name instead), and the
process was not so simple.
I created a button to make it easier to insert (and select the
"reference" check box), but it's still less convenient than
drag-and-drop (or copy-and-paste) which is still possible. If I prevent
the latter actions by making the field read-only, the button also
doesn't work. And either way, the pdf image is not displayed. Is it
possible to improve these things?

And finally, I tried inserting an object (create from file). It behaves
just like drag-and-drop (database jumps to 11 MB), regardless of the
"Link" option. If I select "display as icon", the database grows "only"
to about 3 MB, but obviously it displays an icon instead of the pdf
image.

Do you know any solution to these problems? If there is a commercial
plugin that helps, please describe what it does and how it works, and
I'll try to rewrite it.

Thanks
Adrian

#2

I'm using FMP8A, but it is similar in FMD7

#3

Your suspicions are correct.

The file size increases by megabytes because an uncompressed bitmap preview
of the file is created and used in the container field. Unfortunately, for
all that space taken up it's not even a very high resolution one so it's not
great (ok, useless) for screen display and printing.

FileMaker could potentially be a terrific application for intelligently
filling out forms you find all over the place in PDF format, except that the
instant you bring a PDF into FileMaker you get this bloated, dysfunctional
bitmap... whether it's a field or layout object.

I don't know the answer to your question, "How can it be so awful?" I'm
particularly shocked that printing a layout to the PDF driver results in
files 10s of K in size, where using FM8's built in "Save As PDF" command
results in files that are 100s of K in size, and more often than not not as
nicely rendered.

And did you notice that "Save As PDF" is *not* available in runtime
solutions created with FM8A?

You'd think their proudly proclaimed incorporation of Adobe technology would
mean intelligent handling of PDFs... but quite the opposite seems to be
true.

Bill

<aditsu (AT) gmail (DOT) com> wrote

Quote:

Hi all,

I'm trying to put files (pdfs and images) into my FM database, and I'm
studying various options.
I added a container field, and first I tried dragging a pdf file into
it. It worked, I could see the (reduced) image in FM, and
double-clicking it opened the pdf in Adobe Reader. All perfect so far,
except that the fp7 file size jumped from 88 KB to 11 MB!!! The pdf has
one A4 page, 48 KB, and it is the only file I tried to insert, into a
single record. After removing the file from the field and compacting
the database, it went back to 88 KB.
What is going on? Does FM store the file internally as an uncompressed
bitmap, or what? How can it be so awful?

The second thing I tried was inserting a file reference to the pdf. It
worked, and the database didn't increase in size, however the image was
not displayed (it showed a pdf icon and file name instead), and the
process was not so simple.
I created a button to make it easier to insert (and select the
"reference" check box), but it's still less convenient than
drag-and-drop (or copy-and-paste) which is still possible. If I prevent
the latter actions by making the field read-only, the button also
doesn't work. And either way, the pdf image is not displayed. Is it
possible to improve these things?

And finally, I tried inserting an object (create from file). It behaves
just like drag-and-drop (database jumps to 11 MB), regardless of the
"Link" option. If I select "display as icon", the database grows "only"
to about 3 MB, but obviously it displays an icon instead of the pdf
image.

Do you know any solution to these problems? If there is a commercial
plugin that helps, please describe what it does and how it works, and
I'll try to rewrite it.

Thanks
Adrian

#4

Adrian,

This is not a problem as filemaker regards it as expected behavior.
Filemaker is not a picture/pdf/wav file storage program. With
dragging/dropping you are asking from filemaker to store various forms of
external files which it doesn't naturally 'expects'. So it has to translate
all the files into a form at can store internaly. And the way they have done
this does bloat the file-size. You wil experience the same when you import a
picture right into a layout (as a background pic).

As far as I am aware there are no workarounds. For my pics I always use a
calculated container, but I have no experience with other formats.

Ursus

<aditsu (AT) gmail (DOT) com> schreef in bericht
news:1129664968.246131.24830 (AT) g49g2000cwa (DOT) googlegroups.com...

Quote:

Hi all,

I'm trying to put files (pdfs and images) into my FM database, and I'm
studying various options.
I added a container field, and first I tried dragging a pdf file into
it. It worked, I could see the (reduced) image in FM, and
double-clicking it opened the pdf in Adobe Reader. All perfect so far,
except that the fp7 file size jumped from 88 KB to 11 MB!!! The pdf has
one A4 page, 48 KB, and it is the only file I tried to insert, into a
single record. After removing the file from the field and compacting
the database, it went back to 88 KB.
What is going on? Does FM store the file internally as an uncompressed
bitmap, or what? How can it be so awful?

The second thing I tried was inserting a file reference to the pdf. It
worked, and the database didn't increase in size, however the image was
not displayed (it showed a pdf icon and file name instead), and the
process was not so simple.
I created a button to make it easier to insert (and select the
"reference" check box), but it's still less convenient than
drag-and-drop (or copy-and-paste) which is still possible. If I prevent
the latter actions by making the field read-only, the button also
doesn't work. And either way, the pdf image is not displayed. Is it
possible to improve these things?

And finally, I tried inserting an object (create from file). It behaves
just like drag-and-drop (database jumps to 11 MB), regardless of the
"Link" option. If I select "display as icon", the database grows "only"
to about 3 MB, but obviously it displays an icon instead of the pdf
image.

Do you know any solution to these problems? If there is a commercial
plugin that helps, please describe what it does and how it works, and
I'll try to rewrite it.

Thanks
Adrian

#5

Surely Filemaker could compress the preview image at the least.

Bill

"ursus.kirk" <secret (AT) nowhere (DOT) com> wrote

Quote:

Filemaker is not a picture/pdf/wav file storage program. With
dragging/dropping you are asking from filemaker to store various forms of
external files which it doesn't naturally 'expects'. So it has to
translate all the files into a form at can store internaly. And the way
they have done this does bloat the file-size. You wil experience the same
when you import a picture right into a layout (as a background pic).

#6

Oh, and this is not actually true of graphics. FileMaker will treat GIFs as
GIFs (transparency), and PNGs and PNGs (alpha channel), so it's not just
blindy converting them to BMP and bloating the file size.

It's not that "FileMaker is not a picture/pdf/wav file storage program" --
it's that FileMaker is not a GREAT picture/PDF/wav file storage program.

Bill

"ursus.kirk" <secret (AT) nowhere (DOT) com> wrote

Quote:

Filemaker is not a picture/pdf/wav file storage program. With
dragging/dropping you are asking from filemaker to store various forms of
external files which it doesn't naturally 'expects'. So it has to
translate all the files into a form at can store internaly. And the way
they have done this does bloat the file-size. You wil experience the same
when you import a picture right into a layout (as a background pic).

#7

ursus.kirk wrote:

Quote:

This is not a problem as filemaker regards it as expected behavior.

So FM is officially and intentionally making fun of us?

Quote:

Filemaker is not a picture/pdf/wav file storage program.

Oh.. then why does it have features like "insert picture", "insert
sound", "insert file" and "insert object"?

Quote:

With
dragging/dropping you are asking from filemaker to store various forms of
external files which it doesn't naturally 'expects'. So it has to translate
all the files into a form at can store internaly.

First, we have a fact - FM is able to create preview images of pdfs
(and also other file formats) and display them in reduced size.
In a logical world, it would store the original file (48 KB) in the
database, and perhaps a preview image (reduced, not full-size) for fast
display. Supposing my field is 120*160 pixels, and the image is stored
as uncompressed RGB, it would take up 57 KB, so about 105 KB in total
for this file. But there's no reason why it shouldn't compress the
image to png or jpeg, thus saving some dozens of KB.
For un unknown file type, or if it can't get a preview image, it should
just store the file as-is (thus taking even less disk space).
I can't imagine why FM doesn't do things this way.

Quote:

For my pics I always use a calculated container,

Could you please describe briefly how you created the calculated
container (what kind of formula?) and how you are using it?

Thanks

Adrian

#8

I happen to have a large museum as client and they obviously want to
have the images of their paintings in each record of each file (FMP6).
So I had to do something.
I then used the Troi File - www.troi.com - plugin which comes with
excellent examples. I diverted some of them to do the following :
- have a special folder shared in the OS sense full of image files - one
file per image. E.g. Picasso012.fpg. Each folder can contain thousands
of files. In fact not more than around 5000 per folder as the files
names are put together in a field which is limited to 64 K characters.
in FMP6.
- then, create a special Images.fp5 file with one record per image and
in it a container field holding the 'reference' (the path) of the image
file and not the file itrself.
- this Images.fp5 file is part of a 50 FMP file solution put on
FMServer5.5. If the name of the image file amputed of its '.fpg' is the
painting ID, a simple relationship makes the image visible in each
record of each file.
- all that is managed - including the possible renaming of the images
files to meet my requirements - by the Troi File scripts.
It works beautifully on a daily basis.
I even adapted this technique to a more complex solution to be able to
manage 30 000 DVD and tapes cover pictures for a solution to a large
parisian store that rents them- 400 movements in and out of films a
day -.
When creating a film record they wanted to copy-paste the cover image
itself from an internet site to their cover container field. In a few
days they imported that way 2 400 small size images and the films.fp5
file jumped from 60 Mb to 170 Mb. They wanted to stick on that procedure
as it was is the quickest way to get the pictures.
I then automated the process in copying the actual images from Films.fp5
to my Images.fp5 file, then creating one file per image in folders,
erasing the actual images from Films and Images.fp5, and reimporting the
whole set of 'references' to those images into the Images.fp5 file. I
use 20 folders to overcome the 64Kb size limit. The process works every
night for almost real time update.
It was not a small task to build it.
I could share with you my actual programs, but a part is in french. That
could still give you an idea of how it has been built. Please request
them privately.
Remi-Noel

<aditsu (AT) gmail (DOT) com> a écrit dans le message de news:
1129664968.246131.24830 (AT) g49g200...oglegroups.com...

Quote:

Hi all,

I'm trying to put files (pdfs and images) into my FM database, and I'm
studying various options.
I added a container field, and first I tried dragging a pdf file into
it. It worked, I could see the (reduced) image in FM, and
double-clicking it opened the pdf in Adobe Reader. All perfect so far,
except that the fp7 file size jumped from 88 KB to 11 MB!!! The pdf
has
one A4 page, 48 KB, and it is the only file I tried to insert, into a
single record. After removing the file from the field and compacting
the database, it went back to 88 KB.
What is going on? Does FM store the file internally as an uncompressed
bitmap, or what? How can it be so awful?

The second thing I tried was inserting a file reference to the pdf. It
worked, and the database didn't increase in size, however the image
was
not displayed (it showed a pdf icon and file name instead), and the
process was not so simple.
I created a button to make it easier to insert (and select the
"reference" check box), but it's still less convenient than
drag-and-drop (or copy-and-paste) which is still possible. If I
prevent
the latter actions by making the field read-only, the button also
doesn't work. And either way, the pdf image is not displayed. Is it
possible to improve these things?

And finally, I tried inserting an object (create from file). It
behaves
just like drag-and-drop (database jumps to 11 MB), regardless of the
"Link" option. If I select "display as icon", the database grows
"only"
to about 3 MB, but obviously it displays an icon instead of the pdf
image.

Do you know any solution to these problems? If there is a commercial
plugin that helps, please describe what it does and how it works, and
I'll try to rewrite it.

Thanks
Adrian

#9

Is .fpg some kind of "French JPG?"

Bill

"Remi-Noel Menegaux" <rnmenegaux (AT) free (DOT) fr> wrote

.....

Quote:

- have a special folder shared in the OS sense full of image files - one
file per image. E.g. Picasso012.fpg. Each folder can contain thousands of
files.
.....

Quote:

If the name of the image file amputed of its '.fpg' is the painting ID, a
simple relationship makes the image visible in each record of each file.

#10

OK, I was not clear.
The 'Picasso012.jpg' is the name of the actual file of the image of that
Picasso painting in JPEG format.
Now, 'Picasso012' is the Painting_ID of that painting in my regular FMP
files.
So by withdrawing the '.jpg' from the name of the image file I get only
'Picasso012' which serves as a link parameter in my relationships
between 'Images.fp5' and the rest of my FMP files.
Am I clearer this time ?
Remi-Noel.

"Bill Marriott" <wjm (AT) wjm (DOT) org> a écrit :

Quote:

Is .fpg some kind of "French JPG?"

Bill

"Remi-Noel Menegaux" <rnmenegaux (AT) free (DOT) fr> wrote in message
- have a special folder shared in the OS sense full of image files -
one file per image. E.g. Picasso012.fpg. Each folder can contain
thousands of files.
....
If the name of the image file amputed of its '.fpg' is the painting
ID, a simple relationship makes the image visible in each record of
each file.