I am refactoring a large multifile database into a group of very simple building block elements. I almost have all the layout overhead removed and need just one more piece to make it really work. Instead of fixed layout elements I use a color theme library. On the layout I wish to use tranparent modifiers to make the interface move in 3D as a context indicator to the user about what needs to be noticed in particular data states ( an interface much like those used in mission simulations ). I know that FM8 handles png images and I have a very complete toolset of photoshop plugins, ect. I just can't get the images into the layout without the background becoming opaque. Can anyone help?

im fairly sure that filemaker doesnt support transparency... you can make something appear transparent but the background will as far as i remember from a long line of posts a few months ago always revert to being opaque...

sorry.... genx

I bought the Theme Library product from Matt Petrowsky and he includes them, further there is a reference at the Moyer group web site that says they do...

" FileMaker Pro 7 offers much improved graphics support. Both the Windows and Macintosh versions have enhanced their support for the PNG format. PNG is a lossless image format that supports alpha channels (variable transparency). Images can appear to have non- rectangular shapes and any part of an image may contain partial or complete transparency.

The following figure illustrates some of the things you can do with FileMaker and PNG images. The large oval image of the sea lions is a container field. A second container field holds the magnifying glass image with a transparent center and a partially transparent drop shadow. The 40% transparent orange circle is a PNG image that was inserted in Layout Mode. The "Lorem ipsum" paragraphs are included in a text field that is placed on the layout behind the images (at left) and also in front of the images.

A closer inspection reveals that FileMaker does a nice job of combining the images. The alpha channels in PNG images are used to create smooth anti-aliased edges. Text also has anti-aliased edges and appears smooth even when intersecting other elements on the layout."

For those interested thereference is:

http://www.moyergroup.com/company/fm7_tips_mar2004.pdf

The theme library transparency pieces operate differently on macs and windows but they provide a monumental new degree of freedom in interaction design.

Darn, the article just doesnt say how you get them in..... : I The Theme libray has them so it can be done... I have tried the insert picture menu command from a png file into the layout mode, copy and past from the scrapbook, and have searched the company and a bunch of web sites

Edited February 13, 200619 yr by Guest
added article reference

...hmmm. what do you know... um... just try right click insert into a global field?

Nope, hmm I tried moving one of the tranparent objects out of FileMaker and into a graphics program. It became opaque as well... But, I was able to invoke the vector gradient tranparency control, so it was embedded in the object while in Filemaker, and it was driving the gradient tranparency of the object in the FileMaker display

This topic comes up from time to time.

In version prior to v7, you had to perform a little magic in order to have it work. There are many posts on how to do this, so one just needs to search.

With the release of v7, FileMaker is more straight forward and does handle transparency created in a program such as Illustrator, and save in the Web format as a png. Ender, aka Mike Hacket also posted a help demo file recently.

HTH

Lee

Two hours of looking for the demo or any description by Ender or Mike Hackett without a transparent background result < whew > I have however read a complete encyclopedia of great advice on almost everything FileMaker.. so thanxs I am helped in all kinds of ways. My Illustrator and Photoshop and Canvas png files still wont enter via my mac. Next I'll try the setup on my Windows machine and the server, maybe its the host :? I'm still stumped.

Somebody call??

Check out the attached demos for a quick explaination of transparency effects in FM7/8.

The Colors.fp7 demo explains briefly how to create the transparency effects.

The Colors_Global.fp7 demo shows the use of globals to hold colors for the different areas of the layout. This sounded kind of like what you are looking for. In my initial tests of this technique, I did see some annoying refresh issues when changing records. This does not seem to be an issue anymore in FM8 (in OS 10.4 anyway.)

Colors.fp7.zip

Colors_Global.fp7.zip

27 min ≠ 2 hours?

I just did a search using[color:blue] Transparent as the [color:blue]Keyword and [color:blue]ender as the user name and it produced 6 other threads, all of which seem to be on the same subject as yours.

Lee

Dear Lee,

I am sorry that you feel irked or that I slighted you in some way or have misrepresented myself. I did spend way more than two hours actually, as I read everything that was to be found under transparency alone which also brought up the stuff you are referring to... but before I posted this thread. I went back after your comment to look and see if i missed something. But I had seen the threads you mentioned. I want to thank both you and Ender for your efforts to help me and I am grateful. Really. So I am, again, sorry that my comment disturbed you so.javascript:void(0)

A third solution I have used, not mentioned by Ender or the others in those threads, is to place a one-pixel by y-pixels rectangle with a solid color filling and a 12pt transparent outside line in a container set to enlarge or reduce without maintaining object proportions. On windows machines this forms an excellent transparent gradient in one direction.

Using a rectangle that is one by one pixel creates a two dimensional gradient. A one by one pixel solid filled circle with a transparent outside line also forms a two directional gradient that has a more subtle gradient effect.

In my example, the Windows gradients are solids on the Mac. There is a similar mechanism that can be invoked on Macs but it then doesn't appear on windows machines.

I have uploaded a file with examples for use by anyone whose application live in ony one environment one machine.

Enders demo program is functionally very much like the functionality am trying to implement on my database. And like that demo file, and the gradient method I mentioned, the problem I am having, is that the patches offered are unable to produce transparent graphic elements that reliably work the same in both WindowsXP and with MacOSX.

In other words, the first respondent may be right, FileMaker doesn't have the capability of displaying transparencies. Its interaction with PNG file contents may not be stable. I was hoping that Petrowski's comments in his product ( Theme Library) would point out a reliable single methodology for cross platform use. I love and use patches, but in this refactoring I am attempting to get rid of them.

[color:blue]To clarify,

Your post said you had search for two hours, but there was only 27 minutes between your post and mine.

Petrowski states that that they do NOT display the same on Windows as they do then Mac, but I don't recall him say that they were not Xplat. He shows the circle pattern. but that is all.

Lee

kmhappel,

I'm afraid your last post is unclear about what the problem is with the PNGs. What do you mean about them not working reliably? Can you show a screenshot of my demo on your Windows box?

Yes, Lee, as I said my comment included the time before I made the post, when I made a similar search to the one you suggested and used the keyword "transparency" before bothering you folks here at the forum and so includes even more time than the counter. I'm sorry that you seem to be hung up on this and that I have somehow invoked a misplaced forensic itch...

The PNG gradients that Mr. Pertowski includes in his Theme Library have the following behaviors (the labels are MP's):

solid transparencies > (MAC) the whole area has the same amount transparency, (WINDOWSXP) a one directional transparency gradient in x ;

gradient transparencies > (MAC) a one directional transparency gradient in x, (WINDOWS) a two directional transparency gradient fading in both x and y [ I have include jpgs of each ]

This means that a seperate gui design must be kept for each system if gradients are used.

Here is a screen shot of the windows and the mac views of the same layout in Ender's demo. It also shows a difference.

In case its an anomoly of my setup, my home development environment I used to take these shots is:

a Mac 827 MHzG4 640MB RAM Mac OS 10.4.4 with a GeForce 2 MX chipset connected to a cinema 23" screen;

a Compaq Presario Pentium 4 2.8 GHz 540MB RAM, Windows XP Pro version 2002 Service Pack 2 with a 17" 1280x1024 Emprex monitor with an Intel 829 15G/GV/910GL Express Graphics Chipset;

An Advanced Control Concepts (ACC) Industrial server with dual Pentium 4 processors, 2GB symetrical RAM with Windows Server 2003 Enterprise Edition. Ethernet connects them. I am running FileMaker8Pro and FileMaker8Advanced on both desktops and and FileMaker8 Server Advanced on the server.

For PNG and other graphics I use Canvas 10.0.2 on both Windows and Mac with a full range of photoshop plug-ins, Illustrator and Photoshop 6 and a current revision of Adobe InDesign CS Pagemaker that shares the same plug-in suite as Canvas. I also use OmniGraffle4 for transparent effects on the Mac versions of FileMaker8.

Ender, upon reflection, the differences may be caused by the effect I have used to use to create gradients and mentioned earlier. Maybe you used color patches that also had a specified transparent edge line thickness. This will always cause an edge gradient transparency on windows platforms when its container field is stretched and is in reduce or enlarge graphics mode.

FYI I have included three different interface PDFs of a current system I built for a customer. It has 12 different color themes that switch using the kind of design thinking in your demo. I am trying to find a way not to retain the current seperated Mac and Windows versions!

Here are the other two images of my @work workflow management system

I have written an email to the folks at Canvas asking about their experience with the way macs and windows machines might differ in handling png files. Maybe they can shed some light on the subject. The reason that I approached them is, when I imported and opened one of Matt P's gradient png files for editing ( its the black single directional gradient I showed in the screen shots above ), a png control for a radial gradient came up instead of one for a directional gradient control.

A radial gradient control has a point at the center of a rotating circle. The center point sets a position for the radial effect. Two points at the opposite ends of a diameter intersecting the center point of the circle, allow two different colors ( or lack thereof in the case of transparency ) to define a two dimensional gradient effect radiating away from the center point and changing between the two opposing states as a function of the angle around the center point. If the center point of a radial control is attached to a corner of a rectangular graphics object ( or field ) and one of the two circle points is on a corner adjacent to the first, then a one dimensional gradient is created in the direction of the point not on an edge of the object. This may be how Photoshop and Illustrator create one and two dimensional gradients using a single algorithm. Other systems and the png standard also allow for for a pure directional gradient. The directional control has a starting point and a vector defined by at least an end-point. Along the vector may be other points used to define different colors or saturation values or both. Maybe a pure directional reader sees the Photoshop created control and interprets the unassigned point in their implementation of a directional control as having meaning and tries to do something with it causing the two dimensional effects.

Interactions like this might be at the heart of alot of these cross-platform graphics issues and we might be able to establish either a set of best practices or create a graphics plug-in that solves the problem in a standard way for all FileMaker users. Just a thought, anyway. What say you guys?

I'm afraid I am getting nothing meaningful from your examples. Could you open the attached file and show us a screen shot of it on Windows? A screen shot on Mac is attached.

PNG.fp7.zip

Dear Vet,

Thanks, you asked a better question and provided a reference that, I think, is going to solve both problems. The answer to your question is that both inside and outside a field, the red gradients with shadow and the dice from your files behave exactly the same on all three of my machines as host. And here is where your examples have provided clarity.

What I believe Matt Petrowski was trying to do or did was take a rectangular vector object ( not a pixel patch ) of equivalent dimension, 1 by n pixels, and use it to create a type of transparency gradient primitive having a very small byte size that could be used repetatively to provide complex graphics effects in layouts without causing the massive file sizes that result from importing large two-dimensional pixel array graphics.

On a Macintosh, a rectangular graphics object, one by one pixel in size, with or without a transparent edge line fills an entire n pixel by m pixel field with a constant color and saturation if its graphics format properties in Filemaker are set to "Reduce or Enlarge".

On a Windows machine that same single pixel, when placed in a FileMaker container field creates a number of different behaviors. If the outside or bounding line is transparent, the gradient goes from some level of opacity below 100% in one corner to transparent on the two sides not adjacent to that corner ( I attached a picture of this in an earlier note ). If the bounding edge is set to black, the gradient within the field goes from a black pixel in a corner to transparent on the two nonadjacent sides.

I think the problem with the Matt Petrowski's Theme Library and its transparent gradient objects is that as 1 by n pixel objects ( even if png formatted ) they invoke or interact with this already existing gradient producing behavior within the FileMaker Windows version.

His png format graphics objects that have a constant transparency value ( and display that way on a macintosh ) acquire an unintended one dimensional transparancy gradient normal to the one pixel thick axis in a Windows version of Filemaker.

His gradient objects were made with a transparency gradient along the n pixel axis of the array. These display as a one dimensional gradient oriented along the n pixel axis on a Macintosh. In a Windows version of FileMaker, they obtain an extra transparency gradient normal to the one pixel thick axis. This results in the display showing a two dimensional gradient.

A two pixel thick x axis moves the start of the transparency gradient away from the corner pixel and towards the opposing corner. At some point the ratio of the object size and the field size becomes close enough to 1/1 such that the transparent edge falls within a single pixel and at some point its saturation reducing effect ceases to be noticed.

These effects are also present in the edges of the object you provided, Veteran, but the graphics form of the objects themselves have a soft edge and make it hard to detect. In GUI building, these effects become much more noticable if located near to native, axis-parallel oriented rectangular FileMaker objects in a layout.

I am glad this is helping, but I still have no idea what the problem is - let alone two. Frankly, I didn't understand a single word of what you said after your first sentence. FYI, there are no vectors in a PNG image - it's a purely bitmap format.

If you still have a problem, or a question, please present it simply, preferably in terms of what you want to achieve. BTW, I am not a Vet.

I have now used OmniGrafflePro4 to create png format transparency gradients that perform well but must be made in relatively large pieces reducing some of the file size reduction but retaining the type of ease demonsrated in Ender's database. The OmniGraffle gradient also has the transparent edge when stretched out large enough. But maybe I will discover a way around that tonight.

I have been referring to a video and some text in which Matt Petrowski descibes the method he apparently has used to make the tranparency gradient primitives he provides in his product, Theme Libraries. After creating a one by n row of pixels using a gradient tool, he saves them as a png file and imports them into FileMaker. He uses FileMakers "Reduce and Enlarge" function to make gradient fills in his layouts with them. The problem has been that the Mac version and the Windows version of FileMaker have different resulting behaviors when "Reduce and Enlarge" are applied.

Another problem is that a number of graphics programs don't implement the png format very well. Canvas and InDesign CS both cause varying and different types of problems. Some can't produce a naturally transparent background. Some produce objects that when imported into containers and rotated may lose their background, but not always. Canvas actually cannot or does not include tranparency or alpha channel information in their implementations of the png standard. Still others have alpha channel information but are unable or are poorly able to be stretched by the "Reduce and Enlarge" mechanism.

If you look at Ender's demo file, the edges of the stretched areas have a transparency gradient at the edge ( visible as a gradient to transparent- or white because of the background - at the bottom and right edges of his transparent graphics ) on the Windows screen shots. This does not occur when his file is opened in a Mac version of FileMaker.

The difference between "Reduce and Enlarge" in Windows and the implementation on the Mac is that in the Windows version there is a (at least partial) transparent edge around objects that under enough stretching becomes visible as a transparency gradient around the original content.

This effect had been used as a trick to create transparent gradients in windows applications before alpha channel capability was added to handle png formats.

It, however, causes difficulties for cross platform developers who are trying to create building blocks that reduce (1) the amount of pixel movement over the network in server applications and (2) the general file size, complexity and eventual corruption potential caused by graphically sophisticated gui designs that allow the user to modify color themes and interaction styles .

Now having read the png format spec as a result of your comment, the issues boil down to two separate problems the first of which is directly related to png files but not in the way that it at first seemed..

1. Graphics program implementations of png file format specs have issues about their compatibility with the png mechanisms in FileMaker - some graphics programs are much more compatible than others. OmniGrafflePro4 is a dirt cheap Mac tool compared to Photoshop but produces great and compatible results.

2. FileMaker's "Reduce and Enlarge" graphics format function produces distinctly different behaviors on Windows and Macintosh platforms. All cross platform applications need to be very careful if the size of original graphics content under "crop" is much different than its size if enlarges. Reduction causes no problems.

I haven't watched this video. I would think that if you wanted to create a 1*n pixels png file with a gradient that can be stretched, the n value should be 256 for a full gradient (from fully opaque to fully transparent). Otherwise you are concatenating artifacts: first the application creating the png has to interpolate the transparency values for each pixel; next Filemaker has to interpolate the same values again for the new number of pixels created by stretching/squeezing the image.

It is quite possible that Windows and MacOS will produce different results with the same file. Filemaker is not a graphics program, and AFAIK a lot of the rendering is farmed out. I don't think this should be critical in a database application, but if it is, you can always design a complete layout in a graphics application, and use it as background image in your application.

That said, I'd like to know if you see any siginificant differences in rendering the attached file.

Untitled.fp7.zip

Comment, Yes they are different. The windows gradient is two dimensional while the mac is one

I see - that's interesting. How about this one?

Untitled.fp7.zip

I think you have now recreated an effect similar to the second type of difference, the stretched transparent edge. the first was like the small or single point width effect.

Well, since I know what's in the png, I can tell you the rendering in Windows is plain wrong. You could probably get the right effect by keeping the image in its original height (4 pixels in this case) and duplicating it instead of stretching downwards.

This apparently is a bug on the Windows platform that Petrowsky pointed out either in his template or in an article on his web site. I also ran across it, and while it never happened in version 6 or below, it happens in 8. You can't stretch a graphic without the right edge going 'crappy'.

Steve

I'm not so sure it hasn't happened all along since I have used it back in 5.5 to make round edges and caused it once on my Mac by copying graphics at a different zoom level than the zoom level I pasted it into a container.

I fooled around last night with several programs and discovered that nearly all of them cause or retain transparent pixels around graphics. Some seem to add them to images to make room for one pixel wide frames of various sorts. Its those transparent pixels that the FileMaker function seems to be interacting with.

I don't think its a bug in Windows. I really think it the graphics programs we use to create the pixel patches and the type of format interpreters ( ie. different chosen by FileMaker for the different platforms ). What might be Windows fault is their lousy handling of pixels in the first place. Even with fonts, the management of pixels is clearly designed for the display of very tiny font sizes in things like spreadsheets and not an approach to WYSIWYG such as using postscript to drive the display.

The png in the first file (the green one) is exactly 1*256 pixels. The leftmost pixel is completely opaque. If you know of a way to add transparent pixels around a single pixel, and still retain the original size, then you know more than I do.

Comment, please, I hope you're joking. If you were joking the jokes on me and all apologies are owed and offerred for the following maybe I got a little thrown by the minute count thing earlier and comments like it all over the Forum

( For anyone else the demo file and description of a pixel, a pixel object and a png file of a single pixel, might be illuminating ) .

But, if not, I request that we tone down the attitudes in here. I have repeatedly followed discussions in the Forum where truely arrongant assumptions were made by advice givers about the both the topics and the people communicating them. You have said several times in your remarks that what I was saying was un-interpretable, but in the end you have the created the same behavior made by exactly the same process I have been describing, you were unfamiliar with the reference point of the description but that doesn't mean that it was wrong. Further, the example you initially offered as a starting point ( here show me why what I know works doesn't) had nothing to do with the problem and the problem could not be invoked by it. It was, however, proof that png can be imported and have transparency correctly displayed and so eliminated that for me as a possible cause. While I knew nothing about PNG, I was quoting people who the FileMaker world seems to honor and who were taliking about creating "native Filemaker objects" for gradient transparancy". I now know this to be untrue and will email M pattrowski about it. So excuse me, comment, but I'm not an idiot or deluded. Ignorant maybe and I work dilligently at reducing that and ask your patience. Otherwise who needs a Forum.

It just seems strange to me that superior knowledge would express such intemperance, given that the expertise I do have has taught me that that it doesn't come easily.

I made several graphics pixel patches last night that were one pixel by n pixels in the graphics program. When saved to png files, I used a IDE tool to look at the raw file. Hmmm.

In some cases the patch content was 3 by (n+2) and in others it was 1 x n. In some it was much larger. I then used an IDE to watch the graphics patch assembled in RAM for display. Four out of five programs had some type of pad to ensure that the outer pixel of the body was not overwritten by the frame. They were also inconsistant in the number of edge or frame pixels that were assigned to the event map for the object. When you create a 1x1 pixel rectangular object in filemaker and the size window says that it is 1x1, is its actual frame 1x1? No its something else.

I have included a small filemaker database with some examples from this little project. Notice that a single pixel cut and pasted from a graphics program is one pixel in framemaker, but after being made a one pixel png file and inserted as a picture, it is now a large pixel patch. It is not just a random fact that after 50 years the software community has been unable to agree on a single, fundamental graphics standard defining exactly what a pixel is and isn't.

So i guess i do know more than you, about this, but it would never occur to me to be so rude as to assume your ignorance or to taunt you because of your ignorance. I have worked on software projects in defense that when people didn't know that they didn't know and someone pointed it out and they couldn't hear them, someone died at some point for that arrogance. Now moving along...

My guess is that FileMaker bought different building-block codes like quick-time for the mac and something else for windows they have differing ways of unpacking and interpreting the files and building pixel displays. It could also be the difference in pixel pitch between these significantly disjoint pixel machines. I've seen stuff like this endlessly in the defense work I've done because the pieces are all done by subs and integrated after their creation discovered the missing spec bits that could have stopped behavior like this.

BTW, I heard from Canvas (ACD) that they don't include alpha channel information at all in their implementation of png. Hence, I couldn't get rid of the white background in their png files even though they were transparent while in their program. They said they had "had some requests for that transparency but it is still in their R&D dept." Strange, eh?

pixel.zip

Well, I had left this thread for a while as it drifted into "Windoze" territory, which I have no way to test. But I must say I think you're reading entirly too much offense into people's suggestions. First with Lee, then comment. Lighten up a bit, eh?

Anyway, good luck with your transparency issues. I'm afraid I can't quite fathom how your 1-pixel transparencies work either. ???

...but it would never occur to me to be so rude as to assume your ignorance or to taunt you because of your ignorance.

I have never known Michael (comment) to taunt. And he is MOST tolerant of ignorance - he puts up with me.

Each person who offers assistance here has a different style. I talk too much. Comment is concise. Don't misinterpret someone's style as their ATTITUDE. I realize it can be frustrating when attempting to explain but reverse it ... it is difficult to get into someone else's head and see what they see and then hold the responsibility to provide accurate, helpful assistance. It would be SOOOOOOO easy just to walk away. But comment kept attempting to help. Tolerance and grace goes both ways.

I have no idea what you are talking about either ... but then I'm using icons I've had since 1991.

Well, you may have just lost some of the the best help you could have received. I wish you luck on finding your answers. It reminds me of my favorite saying (I have many favorites) ... "Never insult an alligator until AFTER you've crossed the river."

LaRetta

I am not joking, but I am raising an eyebrow at some of your statements. And I am not about to enter a contest of 'who knows more'. This comes not out of arogance, but out of total lack of interest in such matters. When I said I didn't understand what you said, I meant precisely that. Your use of technical terms is mostly unfamiliar to me, in spite of being quite familiar with the terms themselves.

AFAICT, the only issue here is the incorrect rendering of a png file with transparency, placed into a FM layout, on the Windows platform. I don't know what native Filemaker objects have to do with this. Native Filemaker objects have no transparency at all, so if you hear someone talking about "creating native Filemaker objects for gradient transparency", safely ignore them. I'd be very surprised to learn that Matt Petrowsky said anything like that, and I fear you might be doing him grave injustice by suggesting that he did so.

Let me also put another issue aside, and that is the difference between the size of an object on one hand, and the size of what you call "the frame". A 1x1 pixel object is always 1x1 in Filemaker. But that object is on a plane of its own. This enables Filemaker to move the object, if required, to another location or backward/forward on the z axis. So a FM layout is not a single flat plane, but multiple planes layered one on top of another.

However, the display has only a single plane, so before a layout can be displayed, the various planes need to be married together. Also, native FM objects are vetor-based (they can be resized with no loss of quality), so these need to be rasterized (mapped to pixels).

Now, it is quite common, when rendering layers into a flat bit-map image, to apply anti-aliasing to the edges of objects. This is creating an optical illusion that minimises the 'stair-case' effect on round or slanted edges. So when you look at the rendered flat image, be it on screen, or in the buffer of a graphic card, the object may seem to have grown in size, as the result of fuzzy edges. Different applications may apply different amounts of anti-aliasing (and different algorithms), so it is not surprising if you've noticed a difference in the results.

I have reasons to believe the Filemaker farms out the entire rendering process to the OS, rather than performing it "in-house". Since I don't have access to the FM application code, I cannot be sure, but various indications point to this (LaRetta's dancing phone being one of them).

So what it basically comes down to is that Windows does a very poor job of it, both in interpolating the transparency values over the stretched image, and in anti-aliasing its edges. IIUC, there is no problem if the image is not enlarged, so the concusion seems to be not to stretch png images in Windows.

Well, so much for being concise...

Just for the record I need the forum.

Without this forum and the cafe I could not have achieved what I have and I am truly grateful.

As in all walks of life the folks around these places are as varied as they are many but they all have one thing in common - a readiness to share, which is a quality in ever decreasing evidence in modern society.

I find the world a better place for that.

Phil

Edited February 16, 200619 yr by Guest
should have been in reply to KMHAPPEL

Hmmm. Comment, the problem is NOT simply the incorrect rendering of png files placed in a FM layout on the windows platform, NOR that the observed extra pixels that occur in FileMaker objects are being caused by anti-aliasing during rasterization although it may contribute NOR solely a windows rendering problem ( as horrible as it may be ).

(1) the gradient objects that are included in the Theme Library are described by Matt P. as having been imported through the means of a png file. These objects have embedded in them vector controls for radial gradients which, if they were reduced to simple pixel patches by the process of being formatted by Photoshop as png files, could not occur or be reintroduced;

(2) the effects can also be caused by objects that have never been in a png file such as FM graphics objects;

(3) if anti-aliasing is causing the extra pixels, there is still an unexplained issue. Anti-aliasing processes normally produce interpolated color values that define opaque pixel colors, not transparency masks, So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information. Alpha channel information is organized on programming abstraction levels well above the operating system, BTW so are the layers.

(4) If the problem is a Windows issue alone, then it would seem reasonable that the problem would be invocable across a wide number of programs, yet it is not a widely known phenomenon.

(5) object layering is defined well above the operating system or card driver, the grouping and assignment is probably a pure FM process. It maybe using a standard intermediate code library such as Quicktime or x-code on the Mac.

(6) The stretch breakdown is not just oriented to the right but towards the right and towards the bottom regardless of the options set in the reduce and enlarge options ( such as center-center or bottom-right ) but only when the object is close to one pixel by one pixel in size. This is certainly not an attribute of Windows.

(7) The png file created in a graphics program whose content is a single pixel definition, may be inserted by FileMaker as a pixel patch that not a single pixel. This is clearly a problem between implementations of the PNG standard in various programs;

(8) the problem is mentioned as not existing in extension, its reduction rather than extension and, more correctly, if the pixel patch is equal or greater in size to the display frame. Even more important is that under reduce or enlarge, and

(9) the right-bottom transparent edge gradient effect has been able to be recreated in Mac versions of FM.

For the rest, if I am wrong I apologize. I will lighten up. And it is very clear to me, Inky, that I also need help with filemaker and I also am very glad and grateful for assistance that addresses my problems.

As for raised eyebrows, well...

the gradient objects ... having been imported through the means of a png file. These objects have embedded in them vector controls for radial gradients

No. I'm afraid you're repeating the same mistake. There are no vectors in a png file.

the effects can also be caused by objects that have never been in a png file such as FM graphics objects

Anything is possible, but I see nothing that would point to such possibility (see Occam's razor).

Anti-aliasing processes normally produce interpolated color values that define opaque pixel colors, not transparency masks, So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information.

The pixel information *is* both color AND transparency. When two (or more) pixels occupy the same position (layers), the rendering engine needs to decide what the color of the final pixel should be. This decision is based on the pixels' color, their transparency, and layer stacking order (front/back). For anti-aliasing, the information from surrounding pixels is also considered. Needles to say, when rendering for screen, the resulting pixel is fully opaque.

So there is some mechanism that that sees the pixel information as alpha channel (transparency) information instead of pixel information.

See above - the rendering mechanism sees pixel information as BOTH color AND transparency.

Alpha channel information is organized on programming abstraction levels well above the operating system, BTW so are the layers.

Here's an example of sentence that to me carries no meaning. Alpha channel information is written in the png file as a number between 0 and 255, per pixel. A fully red, half-transparent pixel is an array of {255 ; 0 ; 0 ; 128 }. I see no abstraction here.

If the problem is a Windows issue alone, then it would seem reasonable that the problem would be invocable across a wide number of programs, yet it is not a widely known phenomenon.

That is a good point. OTOH, if it is Filemaker, why doesn't it happen on OS X?

Fact is, I have no way of knowing whose fault it is - I can only surmise. Let FMI and Microsoft work it out between them.

Meanwhile, I googled for "+png +Windows +transparency +problem" and got 347,000 hits - so maybe it's not such a good point after all.

I'm afraid I can't quite fathom how your 1-pixel transparencies work either.

I would suggest that you make some one pixel rectangles in a windows version and insert them into container fields and watch what happens. I don't know how they work either, but they do occur.

Edited February 18, 200619 yr by Guest

Comment, doing the equivalent of yelling doesn't change the basic fact, that what you have to say doesn't address or solve the problem at hand. Putting it on me doesn't help either.

A lot of other people that build graphically complex interfaces to FileMaker databases that are used over networks and the Internet by lots of users concurrently need tools like the ones offered in Theme Library and will run into the problems I have and so I request, [color:red] please stop the rant and be part of a solution.

Edited February 19, 200619 yr by Guest

Because of the question about what Matt Petrowski may have said, I transcribed the text of his comments that have been important to me (the urls are included so that anyone can listen to them themselves).

[color:blue]I bought the Scriptology Theme Library because all the other Scriptology products I have bought have been well worth their price and because the Theme Library in its " Theme Library Overview Movie, http: // www.scriptology.com/index.php?product=theme_library, says

"…when you get to all your gradients, all of these have been have been optimized for FileMaker Pro meaning they're [color:blue]native to FileMaker Pro. They'll refresh really quickly and they'll work really fast over the network especially if you are working with the database over the Internet using FileMaker Pro."

I build databases and data mining tools for people who make decisions based on their perceptions of data states and the relationships of those states to actions they need to take in business. This often means that the interface is as important, if not more important than the data. The interface actually embodies and reveals any value that that is present in the data, and without it the fact of having data is just a cost. Because FileMaker has such a great GUI building toolset I have long used it for prototypes, and with version seven I began to sell projects with it as the final target environment. One problem that constantly comes up is the bandwidth required in networked versions to just move the interface among the users who are constantly interacting with a dynamic data state causing changes in the GUI configuration that need to be displayed. So I was very interested in the Theme Library.

Having received it, [color:blue]Matt Petrowski's Scriptology Theme Library was indeed a GREAT PRODUCT and well worth its price. It had impressive gradients that inspired me to include them in a product that I am building under contract and that work is paying my bills, such as they are. During the use of the Theme Library I began to investigate the different behaviors that the transparency gradients had. I found this movie at FileMaker magazine: http://previews.filemakermagazine.com/videos/599/ThemeListLayout_full.mov "A Layout Designer's Tips and Tricks" It, in turn described how he had made the transparency gradients

"There is only one other thing that I'd like to show you before we finish up. And that is, with regards to a question that was asked about the Theme Library and in particular using transparencies and how you would use those... starting with FileMaker 7 transparencies were supported in the form of the PNG support that's added into FileMaker 7 and now FileMaker 8. PNG supports alpha channels and different levels of transparency, however there is one problem, and according to what I know FileMaker is using the QuickTime library, I know that it is on the Macintosh, but while FileMaker doesn't necessarily install QuickTime I don’t know whether its embedded into the FileMaker application on Windows or what the developers have done but things don’t work the same way on the Macintosh that they do on Windows. Although on windows you do get some nice effects. What transparencies are for and the reason that they're single pixel lines, at least they are for the gradient transparencies and the solid transparencies, are these are PNGs that have been inserted into the FileMaker Theme, ah, Scriptology Theme Library and when you go into layout mode, all you have to do is choose one of the transparencies that you want to use. Lets say for example 50%... you can use this either in a container field or you can use this straight on your own layout...

As I scroll this down you will notice that on windows when you drag out the solid transparencies that go from a solid color down to a lighter color, they will fade or they will blur out as you drag them out. So if I drag this all the way over you can see that the blurring or the blow out or the fade out is going to be much stronger rather than a nice crisp edge which it's supposed to be. On Macintosh this crisp edge is still crisp but on windows it blows out. When you take a look at the transparencies over on the gradient transparencies, and I'll select 30% or 40% copy that ... when I resize this, what you're going to notice ... is rather than a continuous tone that the transparency is supposed to be and will be on the Macintosh I get more of a arc or a circular, actually its a quarter of a circular look when I use this transparency. Now that's just something that's weird that is going on even though this was created as a solid transparency. But I wanted to show you how I created these in Photoshop, its how I created the transparencies for this windows XP theme and many of the other transparencies that are used in the Theme Library...

( He then describes how he creates a “1 x n” pixel array in Photoshop )

The reason is that one pixel, the amount of information is going to be very small and in FileMaker you can drag this out to any size that you need and FileMaker will scale that transparency and it will make the transparency work for the whole layout. The one issue you need to be aware of is, if you have a transparency and you drag this out to the full height of the layout you're going to get layout refresh issues... so the best use of transparencies are typically going to be smaller." ( He then describes how he creates an “m x n” pixel array in Photoshop and explains that this will then cause you to "suffer a bit larger file size" when using “m x n” pixel patches ).

http://www.fmforums.com/forum/attachment.php?attid/6467/

http://www.fmforums.com/forum/attachment.php?attid/6468/

So I opened up my copies of Photoshop, Illustrator and Canvas and discovered that none of them would export a PNG file that FileMaker would import in the way that Matt had described, that is, with a transparent background. I assumed that there was something I didn't do correctly and began to search the Forum using keywords like transparency. I browsed or read every thread on the ten or twelve pages of references that the search brought up. But none of what was offered worked with my programs. So I created this topic.

This still didn’t solve why the objects reported by Petrowski as PNG file imported had vector control components stored in them. [color:blue] Why didn’t I just stop thinking about the subject because it had been said that PNG files do not have vector information? First of all, I have no reason to mistrust Mr. Petrowski as everything I have ever bought from him has worked wonderfully. Second, because Sherlock Holmes once said (ah yes, from the favorite quotes department LaRetta, “when the evidence doesn’t fit the theory, don’t change the evidence” and the object in the Theme Library does have a vector control. Secondly, because I discovered that complete and compliant PNG implementations are anything but normal and the chances are very high that FileMaker has used non-equivalent implementations of PNG and other graphics processes in its two versions.

[color:black]The answer to the original question is: [color:red] Each graphics program has to be individually tested for the way that it creates PNG files and the way those files are imported into FileMaker. Pasting artwork into a container field and rotating it may not work but it is a thing to try. A number of programs work such as OmniGraffle4Pro and Photoshop. However, a current version of Photoshop is required and then only when the 24bit PNG option and the transparency options selected before saving the file for web use. Canvas cannot be used. PNG capabilities in applications have a huge history of bad, incorrect or partial implementations and that there are hundreds of thousands of references to problems with PNG files, transparency, Windows Internet Explorer; there were several hundred that talked about Photoshop and other graphics programs and PNG files. The revision of Photoshop I was using was one of those that did not support transparency in PNG files and that only the most recent revision does support full alpha channel transparency and then only if the “24bit PNG” and “transparency” options are selected. I had also emailed Canvas and they replied that Canvas did not and does not support writing transparency into PNG files even though it says it supports the file standard. BTW non of the references I saw described the FileMaker display issues.