why the common-->../common symlink in doc dirs?

[Lauri Watts]

On Wednesday 17 August 2005 21.05, tnagyemail-ml at yahoo.fr wrote:
> Meinproc could simply use the language reference in
> index.docbook ?

It's just not that simple or it would have been done already when all the 
others were changed to use the help kioslave.

Firstly, the links to the licenses are entities, which require an actual path 
(a real one, or the DTD breaks and all the docs are invalid.)  Since we 
cannot know the absolute path for all installations, a relative one is 
required.  

We can't use the help kioslave to get at the path, because that is KDE 
technology, and our docs could be, and often are, processed outside of KDE.  
The help:/ links for graphics and styles are only used in khelpcenter for 
instance, and we already have to maintain a separate set of stylesheets in 
order to generate docs for the docs.kde.org website, which uses the relative 
path for the docs.  However, that only works for things that are actually 
generated during the processing, whereas entities need to be specified either 
directly in the doc or in the DTD.  Clearly we can't put a help:/ url in a 
pdf that might be read on windows, or versions of documentation placed on 
application websites.

Changing the links to the licenses would require either maintaining two copies 
of all the documents, doing a nasty hack in the XSLT to post-process replace 
the links themselves, or kludging meinproc to do it.  The first is simply not 
happening, the second is doable, but that kind of thing is a slippery slope 
to manage (I would probably accept a patch to the stylesheet doing this, but 
I'm not going to write it.) The last is probably even less likely to happen.

An alternate solution is to simply replace the links to a local copy to a URL 
on the web.  I suspect more people will find that annoying than the small 
percentage actually experiencing the problem (which so far, is a set of one.) 

In any case, this is not a widespread problem causing a huge percentage of 
users any issues.  The default KDE build systems manage this correctly 
without any intervention on the part of the application author or the 
packager)

Regards,
-- 
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050818/d57314f7/attachment.sig>