Containers, file size and references

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

Re: Containers, file size and references

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

Re: Containers, file size and references

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


wrote in message
news:1129664968.246131.24830@g49g2000cwa.googlegroups.com...
> 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
>

Re: Containers, file size and references

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

schreef in bericht
news:1129664968.246131.24830@g49g2000cwa.googlegroups.com...
> 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
>

Re: Containers, file size and references

Surely Filemaker could compress the preview image at the least.

Bill

"ursus.kirk" wrote in message
news:43555a09$0$49131$dbd41001@news.wanadoo.nl...

> 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).

Re: Containers, file size and references

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" wrote in message
news:43555a09$0$49131$dbd41001@news.wanadoo.nl...

> 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).

Re: Containers, file size and references

ursus.kirk wrote:
> This is not a problem as filemaker regards it as expected behavior.

So FM is officially and intentionally making fun of us?

> 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"?

> 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.

> 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

Re: Containers, file size and references

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



a écrit dans le message de news:
1129664968.246131.24830@g49g2000cwa.googlegroups.com...
> 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
>

Re: Containers, file size and references

Is .fpg some kind of "French JPG?" :)

Bill

"Remi-Noel Menegaux" wrote in message
news:43558262$0$24280$626a14ce@news.free.fr...
.....

> - 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.

Re: Containers, file size and references

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" a écrit :
> Is .fpg some kind of "French JPG?" :)
>
> Bill
>
> "Remi-Noel Menegaux" 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.
>
>

Re: Containers, file size and references

Yes, I understood you, I just thought to be a little wise-acre :)

It's a pretty good scheme! And the great news about FileMaker 8 is that it
can be accomplished without the use of plugins as well.

Bill

"Remi-Noel Menegaux" wrote in message
news:4355e17a$0$16087$626a14ce@news.free.fr...
> 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" a écrit :
>> Is .fpg some kind of "French JPG?" :)
>>
>> Bill

Re: Containers, file size and references

>
>> 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"?

dunno, to store very small images??

>
>> 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?
>

here we go:
FileMaker 7 offers the "Insert Picture/QuickTime/File" script commands to
place data into a container field. However, these script steps are limited
in that they must explicitly identify the particular file to be imported.
(You cannot express a path using a calculated value.)

If you want to dynamically control the contents of a container field, you
can instead use either the "Set Field" script step, or auto-enter options.
Both will accept a calculated value as a parameter.

The calculation must result in a string representing the file path in the
same format used by the "Insert Picture/QuickTime/File" script commands.
(Just an in any calculation, literals must be enclosed in quotes.) Supported
formats for the pathname include the following:

file:directoryName/fileName
filemac:/volumeName/directoryName/fileName
filewin:/driveletter:/directoryName/fileName
filewin://computerName/shareName/directoryName/fileName
image:directoryName/fileName
imagemac:/volumeName/directoryName/fileName
imagewin:/driveletter:/directoryName/fileName
imagewin://computerName/shareName/directoryName/fileName
movie:directoryName/fileName
moviemac:/volumeName/directoryName/fileName
moviewin:/driveletter:/directoryName/fileName
moviewin://computerName/shareName/directoryName/fileName

For example:

Set Field [Personnel::idPhoto; "imagewin:/D:/Photos/" &
Personnel::employeeID & ".jpg"]

will set idPhoto to show "23456.jpg" from the D:/Photos directory, when
employeeID is 23456.

When a container field is set using this method, the files are always stored
"by reference" only. They are not copied into the FileMaker database file.
If the original file is moved or renamed, FileMaker will display "the file
cannot be found" in the container field. If the original file is modified,
the new contents will be shown when it is updated.

Calculations may also reference container fields. for example, if you import
a picture "rose.gif" into field, "myImage" then the calculation

checkPic (calculation, text result) = TestDB::myImage

will return:

- "rose.gif" if you imported the picture from disk and stored it within
FileMaker
- "?" if you placed it into the field via the clipboard
- "size: 630,240
image:../../My Documents/My Pictures/rose.gif
imagewin:/D:/My Documents/My Pictures/rose.gif" if you imported it from
disk and stored only a reference to the file.

Using both techniques together, you could handle a situation where a
directory of images had to be moved or converted to a different format,
without re-importing them. For example:

Substitute ( Catalog::ProductImage; "/images/"; "/archived/")

If all the images referenced in your file had been moved to the "archived"
directory.

Ursus

Re: Containers, file size and references

Thank you all for your replies. I will review when I have some more
time.
I also noticed that FM behaves much better with JPEG images (at least
if the resolution is not very high).

Adrian