[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Regarding CGM File Format
Stuart --Yes, I was a little careless about some of the subtle complexities one might encounter in encoding conversion, like the data precisions and their controlling metafile elements (MD and PD). But solutions can be found, as we at (the former) Henderson Software discovered -- we wrote an encoding converter that worked pretty well, and others have done so also.
And you're also right that this -- binary-clearText-edit-binary -- is not a good approach for large scale editing on big complex metafiles. (There are good commercial products for that, I believe.) However it is something that I used a lot myself, for example to tweek a single Metafile Descriptor (MD) element in a conformance test suite instance that had some little problem, etc.
Thanks also for the reminder about Style Parameters (which reside in the XML Companion file, and are used for transient display modification during a WebCGM viewing session.) Again, I was thinking simply in terms of single WebCGM (metafile) instances.
Finally, your caveat about "take care" when translating the state-engine of CGM design into tree structured environments is right on. (I think Peter touched on this a little bit in his LinkedIn post about possible XML Encoding of CGM.)
Regards, -Lofton. At 09:51 AM 1/16/2013 -0800, Galt, Stuart A wrote:
Lofton,I think that there are some subtle differences between the encodings and you need to be careful when you transform from one to the other. For example the VDC type is well defined in binary but not so well defined in the clear text form. The various precision elements (in the descriptor section) also need to be treated differently in the clear text form. I agree that converting from binary to text and back is handy for times when you want to make a simple edit by hand... But if you are going to try to process the whole display tree you will probably be taking the CGM and putting it into your own display list so being able to do that directly from the binary will save a translation step.In terms of "interactivity" yes linking is an important feature. The other commonly used feature is editing the "style parameters" turning on/off interactivity and/or visibility, changing colors, stroke weights, fills, etc.I would also toss out that another thing to consider is that CGM is defined in terms of a state engine. If you are transforming to a framework that is XML (or another tree structure) you might need to consider when/where some state information will need to be repeated.-- Stuart Galt stuart.a.galt@boeing.com (206) 544-3656 (206) 304-2979 (cell) From: Lofton Henderson [mailto:lofton@rockynet.com] Sent: Wednesday, January 16, 2013 9:27 AM To: Tarun Batta Cc: Don Larson Subject: Re: Regarding CGM File Format At 10:47 AM 1/15/2013 -0800, Tarun Batta wrote: Hi Guys, @Lofton: Thanks for your reply. It will certainly help me a lot. No problem, you're welcome.@ Don: It would be great if you could throw some light on the encoding programs which Lofton mentioned.Also, few more queries from my end,1) Please point me to some spec sheet which explains the jagrons (elements, entities and properties etc) used in Clear-Text format.Right now, nothing comes to mind other than:a.) the standard itself -- links below to part 1 & 3, link here to part 4 (clear text):http://standards.iso.org/ittf/PubliclyAvailableStandards/c032381_ISO_IEC_8632-4_1999(E).zipb.) or the out-of-print "The CGM Handbook", Henderson & Mumford, Academic Press.You might find one of the older, "survey" papers helpful, listed here: http://www.cgmopen.org/webcgm/readings.html Maybe Don can think of another resource... Don?2) For what I know that CGM files are interactive (have hyperlink navigation, hotspots, screentips on objects, etc.). Therefore, In addition to rendering the CGM file on the browser what other features are most important to be addressed. For example, with MetaWeb plugin for IE, one can perform operations like zoom, pan, rotate, resize, highlight hotspots, introduction of shapes (like lines, polygons etc), editing, etc.Other than hyperlinking (and its associated behaviors like highlighting the target), there is not much more interactivity that is *implicit* in the CGM elements themselves. But as you point out, there are lots of useful interactive features (zoom, pan, highlight, edit, etc...) that are offered in viewers as what I'll call "sensible product features".Don, any further comment on this? The following will give you guys an overview of my approach,Problem Statement: Currently to view the CGM files on browser we need to have a plugin installed but the same restricts the user to a certain browser. For now, there is no solution by which we could render CGM files on any browser of our choice. Solution: I am working on a client side framework which support all browsers. The end user doesn't have to install any plugin on his/her system. Also, the framework could be scalable so that new feature-sets could be incorporated on the fly.P.S.: I hope you guys would entertain more queries from my end in future as well.Sure, no problem. Keep asking.Question. Do you want your questions shared with slightly larger group of CGM activists/experts of the WebCGM Technical Committee? If "yes", you can tell us so and we'll "Cc" to that group. Or else you could use the public "Comment" button here:https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cgmo-webcgm Regards, -Lofton.On Tue, Jan 15, 2013 at 8:25 AM, Lofton Henderson <lofton@rockynet.com> wrote:Hi Tarun,I'll be happy to answer your questions, to my best ability. (If I can't, I'll turn you over to others.) I notice that you have been communicating with Don Larson also on the LinkedIn thread, so I'll copy him here.At 12:50 PM 1/14/2013 -0800, Tarun Batta wrote: Hi, I got your contact details while trying to fetch information regarding CGM.Currently, I am in process of developing a framework for WebCGM. It would be great if you can take out some time to answer few of my questions.The following are queries,1) The CGM files could be in 3 formats namely binary, character-set and clear-text. Actually, the 2nd encoding -- Character -- has been dropped from the official ISO (and ANSI) standard for some time. (Mid-90s, as I recall.) So that's a piece that you can ignore.In order to write a library I am thinking to convert binary and character-set format to clear-text. After the conversion, I can write a parser which can draw the images by reading the clear-text CGM instructions. So, in this what are the binary and character-set CGM formats and how can i convert that into CGM. You can find the Binary format described in Part 3 of the ISO standard -- ISO/IEC 8632-3:1999: http://standards.iso.org/ittf/PubliclyAvailableStandards/c032380_ISO_IEC_8632-3_1999(E).zip ,which you can find on this page with the other CGM (8632) parts: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.htmlBinary-to-ClearText is a good strategy to get something easier to work with. E.g., I have done it so that I could do simple edits, then convert back to Binary for legal interchange (under profiles like S1000D). There are programs available to do these encoding-to-encoding conversions. For example my former CGM software company had such a program, that is probably still available somewhere in the world. I'm sure that Don can help you here, also.Is this a good approach, or would you suggest anything better?Without completely understanding your end-goal, I'll venture ... yes, seems like a sound strategy. Don, do you have anything to add, or am I missing some point here?Regards, -Lofton. Looking forward to hear from you. Thnaks & Regards Tarun
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]