-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1 Hi, thanks for the very detailed list of problems. I'll have a more detailed look into each of them in the next couple of days.Only short comments are therefor added in between your lines right now. ... Am 20.12.2006 um 20:56 schrieb benoit.guillon: >> Your document is really huge (450p without images) and therefore > not easy to debug. Here is a summary of the troubles I found. Some > are dblatex bugs (that I'll fix) but there are things that dblatex > cannot handle easily or are wrong in the file. I list in the order > I found them. Yep it is pretty large, sorry for that. Up to now we built the pdf with db2latex, but that is dead by now?! >> Mediaobjectco Calspair Format:> ------------------------------> According to TDG the calspair format in the file is wrong:> line 2180:> <mediaobjectco>> <imageobjectco>> <areaspec units="calspair">> <area id="co-window-setup-toolbox" coords="229,37 247,21" > label="1"/>> <area id="co-window-setup-tooloptions" coords="300 400" > label="2"/>> <area id="co-window-setup-imagewindow" coords="20 30" > label="3"/>> <area id="co-window-setup-layers" coords="20 40" label="4"/>> <area id="co-window-setup-brushes" coords="40 60" > label="5"/>> </areaspec>> <imageobject lang="en">> <imagedata fileref="../images/using/standard-setup.png" > format="PNG"/>> </imageobject>> </imageobjectco>> </mediaobjectco> I'll doublecheck that issue in the next couple of days. >> TDG says:>> CALSPair>> The coordinates are expressed using the semantics of the CALS > graphic attributes. The format of the coordinates is “x1,y1 x2,y2”. > This identifies a rectangle with the lower-left corner at (x1,y1) > and the upper-right corner at (x2,y2). The X and Y coordinates are > integers in the range 0 to 10000; they express a percentage of the > total distance from 0.00 to 100.00%. The lower-left corner is (0,0).>> Except for the first one, the others don't respect the format. > Moreover I guess that the scale is not respected since it means > 2.29%,0.37% 2.47%,0.21% which is very small.>> Which tool do you use to render these mediaobject callouts? OK, I never cared for the areaspec elements up to now. I guess I have to now. >> Index UTF-8 mess:> -----------------> line 78664:> <indexterm lang="en" significance="normal"><primary>RozostÅ™it</ > primary></indexterm>>> Definitely a dblatex bug, that currently cannot handle non-ascii > characters in <indexterm>. Puh, so we are not the only ones making mistakes :) >> Cyrillic Characters?> --------------------> Are there really some cyrillic characters in the file? At least it > is translated like this, and I don't know how to render them. A > workaround would be to simply ignore them (or replace them by > simple characters. This could be very well. The manual is written for a dozen languages. Each section of the manual is contained as multi language section in one file. So the structure is something like <sect1 lang="en;de;ru"> <para lang="en">FOO</para> <para lang="de">FOO</para> <para lang="ru">FOO</para></sect1> These files are included into one big multi language xml file and then preprocessed into language specific xml files. So the original section files contain english, german, russion, korean, chinese and lots of other languages. Everything is (should be) UTF8 encoded.As soon as there is a wrong lang attribut, some cyrillic characters could slip into the en version... >> line 103591:> <para lang="en">> This filter is found in the image window menu under> <menuchoice moreinfo="none">> <guimenu moreinfo="none">Filters</guimenu>> <guisubmenu moreinfo="none">Map</guisubmenu>> <guimenuitem moreinfo="none">Спроецировать оР> ±ÑŠÐµÐºÑ‚</guimenuitem>> </menuchoice>.> </para>>> Anchor in Glossterm:> --------------------> line 114237:> <glossentry id="file-bmp-save" lang="en">> <glossterm>BMP<anchor id="file-bmp-load"/></glossterm>>> A buggy thing when anchors are in a glossterm. Must be fixed. I've to admit, that looks awesome.uh, I guess it's valid docbook anyways? >> Non ascii characters in programlistings:> ----------------------------------------> This is the most annoying thing, since I don't how it can be fixed. > A programlisting is a verbatim environment where the characters are > not escaped. Even if I apply a patch so that the text is > translated, these characters are converted to latex macros (except > the iso-latin1 character range) that cannot be executed easily in > the verbatim environment. BTW, such formulas shouldn't be put in > programlistings, but rather in mathematical equations.>> line 116327:> <para lang="en">> <blockquote>> <programlisting format="linespecific">> R = T × B ÷ 255> </programlisting>> </blockquote>> </para> OK, that should be no problem to avoid. IIRC one of our writers evens started to put these into mathematic equations.@romanofski: didn't you? >> In conclusion:>> * Will be fixed:> - UTF-8 indexterms> - glossterm anchors fine. >> * What to do with cyrillic chars? hmm, in the case of the en version of the book they might be just plain wrong in there, but considering that there is a whole document with some hundred pages, we should find a solution. Any chance? >> * Calspair format should be changed in the source.>> * Cannot fix non-ascii chars in verbatim environment. I suggest to > replace them by equations in your case. Agreed. These both are in our field. >> What do you think? I'll see, that we can do our homework in time. Thanks again for the great support. Regards, lexA >> Regards,> BG - ---Remember: There are only two tools in life. WD-40, for when something doesn't move, and should, and Duct Tape, for when something is moving and it shouldn't.So does the universe explode if you spray duct tape with WD-40? -----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.5 (Darwin) iD8DBQFFiZ7PR9mXLVsAbiQRAp9/AKCgjclnIzNCDLvf+FrgCSkFCOenvQCg9egKSiJhVvjAe0Rby82W+LR/84Q==czUv-----END PGP SIGNATURE-----_______________________________________________Gimp-docs mailing listGimp-docs@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
