BTW, my previous message wasn't any kind of papal edict. Only Troy can issue those. :) It was just suggestions that everyone is free to disagree with, preferrably before we implement too much.
And just because I say that I think we should do some things doesn't mean I don't think we should do more. I probably just didn't think of other things, so please add more stuff to our task list by suggesting it here. > > The other major aspect of 1.5.4 will be moving much of the > > functionality that gets repeated in all front-ends back > into the API. > > Rather than creating their own encoding & markup filters (GBFHTML, > > Latin1UTF8, UnicodeRTF, etc.), front end authors will simply tell > > SWMgr which encoding & markup they desire and it will handle any > > necessary conversion for them. This not only simplifies front end > > creation, it allows addition of new formats to the library without > > requiring any more than a recompile. > > A very good idea! But the markup part should be flexible > enough to support > frontend specific handling of HREFs (references, footnotes > etc) as well as > other things like color etc. We should discuss this. Maybe > the markup part is > too complex to do in sword? Yes, we should discuss this. I believe we can probably come up with a fairly flexible solution, but if it's not flexible enough, you could always subclass from SWMgr yourself. Do you think perhaps we should have a SWEncodingMgr that handles character encodings and inherits from SWMgr directly, and then have a SWMarkupMgr that handles markups and inherits from SWEncodingMgr? That way you could subclass from SWEncodingMgr if you have special markup needs. But if you just want a quick and simple front end you could use SWMarkupMgr, tell it your desired encoding & markup, and have it do all the work. In any case, I don't plan to break the current interfaces. --Chris
