2009/2/11 Christian Weiske <cwei...@cweiske.de>:
> Hi Richard!
>
>
>> >> OK. But this class is breaking the links. They all now have an MD5
>> >> hash in the html/php output and are not copied to the correct location
>> >> (actually not copied at all).
>> >
>> > They are not copied because they are referenced wrongly now in the
>> > manual itself. Their fileref needs to be relative to the manual.xml
>> > location.
>>
>> Aha! Just for those at the back (ahem), that means whereas it is currently
>> ...
>> figures/imagick.hello_world.png
>> this would become
>> en/reference/imagick/figures/hello_world.png
> Exactly.
>
>> Especially if a translator needs to change the image (say it contains
>> words or whatever), they would also "translate" the fileref to ...
>> lang-x/reference/imagick/figures/hello_world.png
> Yep.
>
>> There are just over 40 images at the moment. I'll test this out and
>> make the necessary changes.
>> OOI. Is there a reason to add an md5 hash to the filename?
> Images are located everywhere in the file structure which I did not want to
> replicate in the compiled manual. Instead, I chose to have only one single
> directory (images/) in which all image files reside, independent of their
> location in the docbook sources/phpdoc cvs. So that hash is the md5 of the
> file path in cvs, guranteeing uniqueness in the final images/ folder.
>
> --
> Regards/Mit freundlichen Grüßen
> Christian Weiske
>
Currently there is a script which pulls all the images from the
various books into a single location.
My phd build output folder is ...
D:.
+---peardoc
| +---chm
| | \---res
| \---html
\---phpdoc
+---chm
| \---res
| \---figures
+---html
| \---figures
\---php
+---figures
\---toc
So in the final result, there is 1 folder for all the images
(currently called figures) for each build.
The current fileref points to the location of the image in the built
manual, not the image in the phpdoc tree, which I suppose is the main
issue here.
I think having the images stored in the xml structure next to the
documentation (e.g.).
/phpdoc/en/reference/imagick/figures
rather than elsewhere (say phpdoc/en/images for example) would be a
better scenario.
But as you mention, then possibility of duplicate names does exist and
is solvable using a hash.
Currently the filename includes the book (imagick.filename.extension),
which is workable.
So, I would keep "figures" rather than "images" unless the syncing of
the manual on mirrors can remove the existing "figures" folder (I
don't know about the mirroring processes).
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
