On 4 Feb., 00:37, Bruno Postle <br...@postle.net> wrote: > We haven't had any bugs related to the file-format for years, > switching Hugin to a different format at this stage would be > self-indulgent and would bring lots of disadvantages.
How about introducing a new format as an option? Nobody wants to instantly get rid of pto format, and it will remain with us for a while to deal with legacy data. Just when it comes to adding support for new features, pto is approaching it's limits. It was a clear, well- thought-out, simple-to-parse language when it was conceived of: single- letter line headers and field headers, no comments with hidden meaning. The single-letter field headers broke first, and they were the least-well-thought-out part where forseeable lack of capability was sacrificed to parsing simplicity. Why was argument passing changed from -o style to --output style? Precisely the same issue. 'Pure' pto could have been described as a subset of a theoretical language, let's call it Linear-P. This would consist of lines with a header determining the line type, and fields with a field header immediately followed by a small set of permissible data types. The parser would be trivial, the meaning could be easily derived from the parse tree with a few switches. Instead of staying within the obvious extension path and allowing multi-letter line headers like it has been done for the field headers, those ugly meaningful comments were introduced. And it makes them part of the syntax, if you know what I mean. Either you have to parse all comments as being potentially meaningful or you have to introduce the comment-sign-plus-keyword as a separate token in the lexical anlayzer. This is truly ugly. Apparently someone has been very dmg > afraid of breaking the parser of the others. Just maintaining that > nobody has identified some vital > functionality that we need that requires a change to something else. Is, IMHO, too conservative. There actually is an aesthetic quality to software. Having a new format side by side with the old wouldn't do any harm. Have a look at my Linear-P: hugin ptoversion2 instead of #hugin_ptoversion 2 or hugin cropFactor1 instead of #-hugin cropFactor=1 or hugin outputImageTypeCompression"LZW" instead of #hugin_outputImageTypeCompression LZW which anyone who knows pto would instantly understand. And if you were to extend Linear-P just a tiny bit, you might throw in an optional delimiter between the field header and the field value, which would even allow to separate the header from the value with a space to improve legibility: hugin ptoversion: 2 hugin cropFactor: 1 hugin outputImageTypeCompression: "LZW" Foreign dialects would produce an 'unknown line type' which could be mentioned in a warning if verbose output is on and otherwise just ignored. You'd end up with a grammar like ( <line_type> ( <field_header> [ : [ whitespace ] ] <field_value> ) * ) + And if, finally, you allowed a line end character, like C's ; you could even avoid ugly stuff like this single line: i w2856 h4290 f10 v98.7793533696463 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r0.487712061443541 p-2.28434020177989 y159.045363311347 TrX0 TrY0 TrZ0 j0 a0.0155477370542221 b-0.0605873460656281 c0.00848415690914515 d48.2164753457605 e-8.7448354341075 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 Vm5 u10 n"IMG_0065.tif" And I leave it to your imagination how this line would look if you could continue pto lines across several lines of text. So much for my rant. By the way, Linear-P is an allusion to Linear- B ;-) http://en.wikipedia.org/wiki/Linear-B Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
