Am Mit, 2003-08-27 um 11.33 schrieb Sven Neumann: > Any help page could then refer to the freetype plug-in by using > <link xmlns:ft="http://freetype.gimp.org/help" ft:href="top" /> > As you can see, the namespace prefix is irrelevant, we can choose > "ft:" here to keep the notation short. Of course if multiple links to > the freetype plug-in are needed, the namespace can be declard in the > top-level element and the link would simply become > <link ft:href="top" /> > I am not sure how much work is needed to teach the help-browser about > a new link type and XML namespaces but I think it might be worth the > effort. This architecture should allow us to do some nifty stuff and > it will assure that no conflicts will ever arise from help registered > by third-party plug-ins. You possibly also though about how to generate these? It's not just about introducing a new tag to XHTML but somehow you also need to express these in the DocBook source. At the moment I don't see how this could even remotely work as there's simply no way to express relative links which are not resolved at latest at transformation time. There is a way to arbitrarily map references using an external map (which can be autogenerated from DocBook source and I'm actually abusing to generate the mapping for the helpbrowser) however this means: a) the documentation has to be in DocBook (or a new mapper has to be made somehow which could be tricky at least for say HTML directly) b) all referenced documentation has to be know when the docs are transformed which is impossible for obvious reasons. > My proposal would also allow to split the help between the GIMP core > and the plug-ins we ship with GIMP. Just as we do for i18n now, where > there are translation domains for the core, the plug-ins and > script-fu, there could be help domains for the core, the standard > plug-ins and individual domains for Script-Fu, Python and Perl > scripts. Nice idea but tricky to impossible to get right. This map to anything proposal will *only* work if you have some means to do the transformation online (which I'm not opposed to but you are) *or* someone has to teach the helpbrowser about those mappings *and* special crappery has to be installed to not make the XSLT processor barf and produce the "right" results. I'm absolutely against the idea of generating invalid XHTML (read: I will not do this). If this is the way to go it has to be representable in valid XHTML. -- Servus, Daniel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil