forum home | register | profile | members |search | faq
homepage | lost password? | chat room
|
|
QSA ToolWorks Public Feedback Forum forum home | register | profile | members |search | faq homepage | lost password? | chat room |
| QSA ToolWorks Public Feedback Forum > What if Helix Can No Longer...? > Support the Picture Field | You are not logged in. Login or Register. |
| Pages: 1 |
|
| Author: | Topic: Support the Picture Field | |||
Matt Posts: 107 Registered: 2003-02-16  mstrange@mac.com  |
 Posted: Jun 23, 2003 1:25:23 pm    
The Picture field type is quite limited in scope (PICT format only, no I/O, etc.) and should either be significantly enhanced or gracefully retired. Carbonization might force our hand, but to my knowledge the Unix, Linux, and Windows worlds don't understand the PICT format anyway, so the Picture field will be worthless when we get there. We're considering an approach that will convert picture fields into document fields during an Update Collection pass, the PICT files embedded in the Picture fields would be converted into internal documents. The main loss here is the ability to copy/paste PICT data into the field. Perhaps if the Document field type allowed you to paste data into it (creating an internal document on the fly) that would cover the hole. Comments?
|
|||
chuckbo Posts: 42 Registered: 2003-04-09 |
 Posted: Jun 23, 2003 1:55:04 pm
I won't miss it, esp. since we now can display graphic documents. chuck |
|||
Sven Posts: 24 Registered: 2003-04-09 |
Posted: Jun 24, 2003 8:54:49 am
We could live with this. We have made quite limited use of the picture field. We could manage to change the odd occurrence into internal document by hand, but it would be nicer, of course, if it could be handled by an automatic process. Sven
|
|||
keVin Posts: 30 Registered: 2003-04-09 |
Posted: Jun 27, 2003 1:07:13 pm
The Picture field is the tip of the iceberg. How will this affect other PICTs such as those pasted into buttons or in label rectangles? |
|||
| keVin Posts: 30 Registered: 2003-04-09 |
Posted: Jun 29, 2003 1:20:35 am
By enabling data rectangles to be placed in the background, they can be used instead of label rectangles. The data rectangles can display the picture from a document field using QuickTime. This eliminates the reliance for PICT and allows conditional backgrounds. I guess this would also apply to command rectangles. They should also be able to display the content of abaci containing a picture tile. Regarding the Picture -> Document field conversion, in some Collections it will cause duplication. For example, a Relation may have a document with a previously unsupported image type and a picture field with a pasted in PICT. The conversion would not break the Collection (unless internally stored documents are many) but may require modification by the author to conserve space. Curiously, what image type do the new pictures take on? It would appear that TIFF is the likely candidate. Looking within a Collection, I can see instances where the pict->doc conversion would cause a break. LU [pict] for [x] = [x] should result in a displayed picture. If changed to a document, the Abacus result must be placed in a Picture tile. - Edited by keVin on: Jul 01, 2003 6:41:33 pm |
|||
dkuchta Posts: 40 Registered: 2003-04-09 |
Posted: Jul 06, 2003 11:59:05 am
I use the picture field extensively in my collections. To me, the focus of the Picture field is very different from the document management focus of the document field. For document management, it makes sense to do such things as display the file name in one field and, if the document is an image, display a preview of the image in another field. The documents being managed may or may not be images, and the document field has been well designed to handle a variety of document types and support the functions needed by people managing documents. On the other hand, the picture field’s purpose is for quick, easy use of small images and graphics stored within the database. The user (or developer) does not care where or how the image is stored, and has no interest in the stored format, or what the file’s name or location is. In this paradigm, the image (not the file) is simply an attribute of the record, just like a flag or text field. It serves to delineate the uniqueness of the record through visual recognition. One example is a contact database where a thumbnail picture of the contact is pasted in to recognize the person. My particular use is in an equipment database where a small photo of the equipment is pasted in so that the mechanic can recognize the equipment. This photo is printed on work orders, and displayed in many forms in the database as a visual cue that you are updated the records for the right piece of equipment. Currently, I use the picture field for the following: 1) Thumbnail images for recognition of people, equipment, etc. 2) Dynamic graphics on forms, such as a lock icon that is displayed or not depending on whether an item can be changed. 3) Static graphics that are used in multiple locations throughout the database, and therefore looked up from a central location like a global relation. These are items like standard dialog icons (stop sign and warning), and straight-lines for separators of forms. (These could be pasted into a text field, but would have to be done so in multiple locations) If the document field can be modified to meet these needs, that would be fine. Rather than try to figure out how it should be implemented, here are the required features: 1) Images can be copy/pasted into/from the data rectangle. 2) Images are displayed in the same rectangle where they are copy/pasted. 3) Images MUST be able to be exported and imported to allow end users to upgrade to a new structure. Frankly, ANY field that can’t be export/imported is fairly useless. 4) Images can be scaled to the size of the data rectangle (maintaining aspect ratio) 5) Images can be handled in abacus tiles similarly to current Picture field. In other words, they can be looked up, displayed conditionally with if-then tile, etc. Some other “nice-to-have” features would be: 5) Developer can specify a limit to the pixel size of the image. This prevents an unsuspecting user from pasting images from his spiffy new 5 megapixel digital camera and ballooning his database. This could be set by the developer in the format dialog opened from the field’s icon. When the image is converted to the internal format, it would be scaled to this limited size for storage. 6) Allow display at screen resolution, but printing at the resolution of the stored image. This would allow printing of ID cards without the images looking pixelated. Note that there’s no mention of file format in these requirements. It doesn’t matter to the user or, for that matter, to the developer. If TIFF is a more universally available format, then use it. If there’s a way to modify the document field to meet these requirements, that’s fine. If not, there should be a separate field to meet these needs. -Dan Kuchta - Edited by dkuchta on: Jul 06, 2003 12:15:10 pm
|
|||
| Bob Posts: 5 Registered: 2003-07-06 |
Posted: Jul 06, 2003 4:48:04 pm
Our use of the picture field is for a finding aid for historical photographs and artwork. Having the field limited to PICT has been inconvenient. Converting the field into an internal document would be an improvement for our circumstances.
|
|||
| DanielKegan Posts: 1 Registered: 2003-07-07 |
Posted: Jul 07, 2003 10:49:18 am
Some simple graphic field is very helpful. We currently use the Helix picture field in our client dataabase for pictures of clients. If pict will not be supported in the future, then having a pic field with a common or native OSX format could work also. tiff, jpeg, something common and not large. Can deal with one-time conversion from pict to something else. A small field of graphic is not the same as a separate document, and using document field feels kludgy when what is reallyw anted is a simple graphic.
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: Jul 07, 2003 11:03:57 am
Sure, but you can't paste a graphic into an XML file. You have to pass a URI. (Unless you want a huge byte encoded stream in the XML file, which would be a very cumbersome, albeit doable proposition.) So the question remains: do we stay in the Helix proprietary format or do we embrace industry standards? You (probably) can't have your cake and eat it too. (what does FMP do for picture fields? 4D? Access?)
|
|||
| keVin Posts: 30 Registered: 2003-04-09 |
 Posted: Jul 07, 2003 12:37:35 pm
It seems the Picture field fills a particular need. How the image is stored is inconsequential to the users. They just want to paste a picture into a square and use it via lookups. By means of a user preference, perhaps the image can be converted into TIF, GIF, or JPG that is stored internally as BLOB. Essentially, the Picture field would function as the Picture tile. During export, the picture field dumps the document and provides the destination path like other documents. During import, the document is loaded into the internal BLOB library and displayed by the Picture field. I have a modified version of SimpleText that does something similar. It is possible to paste an image at the insertion point. When this is done, a numbered PICT is created within the resource fork. I do not recommend storing images here or using PICT but perhaps it demonstrates the concept of a hidden internal image library that can exist within the Helix Collection. |
|||
| lucidlee Posts: 18 Registered: 2003-04-09 |
Posted: Jul 09, 2003 11:22:12 am
quote: Matt these XML comments are out of the blue (for this thread). Would you mind elucidating the background here? If, for example, you're suggesting that Helix may be supporting XML and you are looking for ways to integrate it with graphics management then I would say go with the standards. Those who are relying on Picture fields must be in the minority given their limitations. Having said that I 've just run into problems with EPSF files that I've used in a couple of templates that no longer print because I've replaced the Postscript printer with a non postscript one. It would have been much easier were I able to specify for Helix to convert the graphic on the fly than go into say Graphics Converter and produce a PNG to replace the EPSF. BTW PNGs seem to me a whole lot cleaner, better and safer to use in MS Word docs and while they haven't been mentioned here and don't seem to have won much popularity I would like them supported in Helix.
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: Jul 09, 2003 2:32:42 pm
quote: All I'm saying is that if Helix is to have meaningful data exchange between itself and any other platform or database, you simply can't expect the picture field to work. The byte stream probably wouldn't make sense (and might cause problems, what with the high order bit and all) and certainly would be worthless in a cross-platform situation. I'm not saying that we want to remove the picture field, and we probably won't, but if it prevents us from getting to OS X or (gasp!) Wintel, then is it worth investing dollars in propping up a limited format? Final note: We certainly won't do something that required everybody who has used the Picture field to rework their collections in order to upgrade. The transition has to be automatic and transparent. - Edited by Matt on: Jul 09, 2003 3:05:24 pm
|
|||
| dkuchta Posts: 40 Registered: 2003-04-09 |
Posted: Jul 11, 2003 9:44:40 am
>> meaningful data exchange between itself and any other platform or >> database, you simply can't expect the picture field to work. I think you have to separate the concept of the picture field from its current underlying implementation. The Picture field's current behavior is on the money except for the fact that it doesn't export/import. Again, the user or developer doesn't care about the underlying format for this field's intended use. If you change the underlying format to something like TIFF, then importing and exporting should be practical across any range of platforms. The picture field works fine - just change the internal format. -Dan Kuchta - Edited by dkuchta on: Jul 11, 2003 9:50:44 am
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: Jul 21, 2003 11:34:52 am
Summary: Picture field will (almost certainly) remain unchanged for the Helix 6 release. Helix 6 will run on only Mac OS 9/10, which both understand the PICT format.
|
|||
| Jeff Turner Posts: 4 Registered: 2004-10-31 |
Posted: Nov 02, 2004 10:21:06 pm
Matt, This is a subject near and dear to my heart. We use to import images in jpeg format that were between 200-300k. This worked fine until we tried TCP/IP networking and the collection hit about 78MB. We suddenly had "fatal damage" when running utilities. We stopped TCP/IP networking but still had "fatal damage". We deleted all the image files and suddenly everything was fine. We would like to keep images in our collection, but are afraid to at this point. - Edited by Jeff Turner on: Nov 02, 2004 10:22:19 pm
|
|||
| Jim Whitin Posts: 1 Registered: 2005-05-06 JTWhitin@aol.com |
 Posted: May 06, 2005 11:57:49 am
Matt, WOuld it be possible to handle the pictures (picture files) in the same way that iPhoto does? It would seem that that would be a solution if you're still working on that aspect of Helix 6? (Pictures are stored in a special folder on the harddisk away from the other data of the application.) JImWhitin
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: May 06, 2005 6:13:19 pm
Ummm... that's called an "external document" -- which is what we <em>will</em> support in the future. What will (probably) die off is the internal storage of PICT data type. The corrolary would be if iPhoto were to require you to open your pictures with Preview, copy, then paste them into an "iPhoto document." The distinct picture document would not exist and your only copy of it would be 'buried' inside a cryptic, proprietary format document that only iPhoto could open. Can you now see why the Picture field is not worth updating?
|
|||
| dkuchta Posts: 40 Registered: 2003-04-09 |
Posted: May 08, 2005 10:17:10 am
Matt: I can understand why you no longer want to support it if you consider its use to be managing photographs. But the Mac is a graphically rich environment and a friendly UI makes use of many graphical elements that are small, dynamic, and only used internally. I use the Picture field rampantly for this purpose. I suspect Kevin Williams does too with his beautifully rendered UI's. For this use, no one cares what the internal format of the image is; PICT, TIFF, JPEG - it just doesn't matter. Pick one, use it internally and be done with it. But please continue to support the Picture field. Without the picture field, it will mean that my collections will need 30 or 40 tiny files kicking around with them to contain the icons and other UI graphical elements. This is not an elegant solution. You made mention in a previous statement in this topic that Helix 6 would probably continue to support the picutre field. Has that direction changed? -Dan Kuchta
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: May 08, 2005 2:27:50 pm
quote: Data that can't be exported. Data that can't go cross-platform. I can't figure out why people are so desperate to keep this obsolete format. quote:Use internally stored Document fields to avoid this. quote:WHAT?? How does a simple "we won't be enhancing the Picture field" comment blow up into this??!? go back and read this thread. I never said we were dropping support for pasted graphic elements. If you want to paste a pretty picture into your template, that's fine. quote: No. I don't understand why this is so hard to grok: The Picture field as it currently exists in Helix is a limited, PICT-only, non-exportable, not manipulatable data format. The PICT format is not cross-platform. The PICT format is vastly inferior to GIF, JPEG, PNG, and a dozen other data formats. Contrast that with the Document field as it currently exists: It supports a multitude of data types. It supports both internal and external document storage. It is exportable. It uses QuickTime, so it supports a wide variety of formats and automatically gains more as Apple enhances QuickTime. In short, it can do everything the Picture data type can do, and much more. Maybe it needs to be spelled out a little clearer: Our efforts are going into <i>enhancing</i> the Document field. If I had to choose between the Picture field and Document field, <i>as they exist today</i> I might be reticent to give one up too. But do you really think we're going to leave the Document field back in the 80s forever? Don't you think we'll add drag and drop, in-field rendering, motion formats, etc. to it? I'm sure the argument can be made that these things could also be done with the Picture field, but given the scant resources we have, which one should we expend effort on? The one that can be exported/imported, or the one that can't? Is there really a reasonable argument in favor of the Picture field? The point is this: if you want to write code that will <i>gain</i> capabilities in the future, use the Document field. If you want to be prepared for the future, start looking for ways to use Document fields instead of Picture fields. If you don't care, keep using the Picture field type.
|
|||
| dkuchta Posts: 40 Registered: 2003-04-09 |
Posted: May 09, 2005 8:42:24 pm
>> What will (probably) die off is the internal storage of PICT data type. Since the only internal storage of PICT is the Picture field, this statement concerned me that the Picture field is going away. Which is why I asked the question about Helix 6. >>WHAT? ... If you want to paste a pretty picture into your template, that's fine I don't want to paste graphics into the template. I want to have dynamic graphics that change depending on what selections the user has made in the UI. This requires the use of a data field of some sort. The internal document can fill this role, but it can't currently fill all the roles that the Picture field fills. >> Don't you think we'll add drag and drop, in-field rendering, motion formats, etc. to it? Not necessarily. Since the future directions of individual features aren't known to the general public, I can't really guess at which things will be implemented and when, and if they'll be in place before the picture field dies. This is great news that these features are being contemplated! >> If you want to be prepared for the future, start looking for ways to use Document fields instead of Picture fields. Unfortunately, I can't do that in all cases. Some of my uses for the Picture field are for people to copy-and-paste thumbnails into records as small data elements, not documents to be managed. At this point, the document field requires the user to create an image of the right size, save it, click on the Document field, and navigate to the directory where the file is. And after that, it shows up as a file icon, not a picture. It then requires a separate rectangle to display the file using a Picture tile (unless I'm doing something wrong). I've tried to use this technique in one of my collections and my users found it very confusing. This is in contrast to the Picture field which only requires the user to select a piece of an image he's viewing, and copy/paste it into the Picture field which then displays it. Its nice to know that the Document field will have more capabilities in the future, but I can't use it for this kind of functionality right now. If the document field covers all of the picture field capabilities in the future (copy/paste, AND displaying a picture in the same rectangle), then it will truly be able to replace it. But until then, I still need the Picture field so I'm glad its still planned to be in Helix 6. Thanks!
|
| Pages: 1 |
|
| Lost Password? Powered by UPB Version : 1.8 A script by PHP Outburst |
