Is there any way to isolate the pixel dimensions from a GetAsText ( Image ) string so that they can be used to plug into html code?

GetAsText ( Image ) produces something like:

size:501,341

image:My Images/picture.jpg

imagewin:/D:/Database/My Images/picture.jpg

...whereas html requires syntax like:

height="341" width="501"

...so if I could isolate the height and width dimensions into individual calculation fields, I might be able to plug them into another calculation that generates the body of a simple web page for all the images of a given set (see my previous question). I might have a hope of solving this myself, but am stumped by the variableness of the pixel dimensions. They could be anything from 2 digits each to four digits each, and all combinations in between (e.g: size:97,286 or size:1024,768 etc).

Is this solvable?

width:

MiddleWords (Substitute ( Image ; "," ; " " ) ; 3 ; 1 )

height:

MiddleWords (Substitute ( Image ; "," ; " " ) ; 2 ; 1 )

Edited May 25, 200619 yr by Guest
comment right suggestion

That's an interesting one - and the documentation in the FMP help system is wrong.

The numbers you require lie between the colon and the comma and then between the comma and the first return. You can identify the characters and their positions in the text by using the POSITION function, then use the GetAsNumber function to convert the strings.

Have fun, but be aware this appears to be an UNDOCUMENTED feature and may not be supported in future versions.

Edited May 25, 200619 yr by Guest

Wow, that's so clever Daniele - your solution actually seems to work. Amazing.

I've run into another problem with images imported automatically, however, and have posted it as a separate topic (they seem to be treated differently and the pixel dimensions aren't present).

Thanks heaps.

Edit > Delete (top left). While you're at it, you might want to get rid of the GetValue() - it's not doing much, and you'll get v.7 compatibility as a bonus.

the documentation in the FMP help system is wrong.

...

be aware this appears to be an UNDOCUMENTED feature

The documentation is wrong where? Which feature are you referring to?

Here's the Help system page for the function.

Do you have something different?

GetAsTextHELP.pdf

I don't see anything WRONG on the page. GetAsText ( Container ) returns different results depending on the method the container was populated. These variations are not described.

These variations are not described.

Undocumented?

The help page is not wrong, all I said was that it did not document the features being discussed. in fact, what it does document is too little to be trusted, especially as this topic has demonstrated that the content is variable.

Edited May 25, 200619 yr by Guest

I see a difference between a feature being undocumented vs. inadequately described. In any case, I'd suggest you read this recent thread.

As a postscript to the initial question for the sake of anyone else trying to implement a web export of pictures in the future, beware of a problem that I have discovered:

As of version 8, Filemaker has a very annoying insistence upon resizing the display of images based upon their dpi setting. This means that two images of the same pixel dimensions but differing dpi settings will display at different sizes in Filemaker (like they would in a print layout program, but very unlike anything to do with the web, where dpi is ignored).

Worse yet, Filemaker actually calculates its stored height and width data to display the image at the print size. This means that any attempt to export that data into a web page layout will carry over the wrong pixel dimensions, and you'll get typically squashed or tiny pictures displaying for all those that happen to not be at the standard 72 dpi used for screen viewing.

So you can either leave out the dimensions from your html code, which gives slower page loading, or fix it in another program afterwards. Dreamweaver, for example, has a resize button that will do the job one image at a time, and somebody offers an extension that will do all images at once (search the Dreamweaver exchange).

Better yet, submit a request for Filemaker 9 and beyond to offer optional handling of image display to suit both print and web workflows.