On 5 Feb., 23:01, Bruno Postle <[email protected]> wrote: > On Sat 05-Feb-2011 at 02:43 -0800, kfj wrote: > > >On 4 Feb., 00:19, Bruno Postle <[email protected]> wrote: > > >> They are all comments, so you can ignore them when stitching or > >> optimising. They do carry information used by the GUI. > > > That would imply that the GUI later on has to look at the pto again to > > find those 'comments that carry information used by the GUI'. Wouldn't > > it be the point to have a single parser for all pto that it also > > supplies these data in an internal representation? Other software > > would be free to ignore it, but having to reparse the pto to extract > > some more data sems silly. > > I don't know what you are trying to say here, who is reparsing the > .pto file?
Let me explain. As I understand Daniel's work, he is creating a parser for all pto-using programs, so they can all share the code and there is a common base. When hugin opens a panorama, it reads all information from the pto file, including the hugin-specific data which come in the guise of comments. If Daniel ignores these data in his parser, the result of it's parse can't have the hugin-specific data in it. But hugin needs them, and in fact writes them to the pto whan it saves a panorama. So if hugin were using Daniel's parser, to get hold of these data on opening, hugin would have to look again at the pto file to find the data which Daniel's parser has ignored. This is what I meant by hugin having to reparse the pto file. If I suffer from some misconcetion in this regard, please explain to me what I fail to see. > Is it? What exactly is this feature that the .pto format is > preventing? I feel it's preventing software like hugin from extending it in a clean, consistent way. As I say, it's not only a technical notion, but also an aesthetic one - but often aesthetic judgement can lead to better software, as well. I really don't want to argue about this point any more, and I had never commented on it again if it hadn't so happened that Daniel has written a pto parser, and so have I, quite recently. I'm entitled to my opinion about pto, languages, parsers and aesthetics and I hope I am free to express them here. So please let's not argue any more. I agree it's not a core issue, it just so happens that I have done a fair bit of computer language design, that's why I have strong opinions about the topic. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
