Bug 31525 - openjade-1.3 has known (SourceForge) bug with a fix
openjade-1.3 has known (SourceForge) bug with a fix
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: openjade (Show other bugs)
1.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Brock Organ
http://sourceforge.net/tracker/index....
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-12 12:37 EST by matti aarnio
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-14 09:49:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch -p3 (315 bytes, patch)
2001-03-12 17:27 EST, matti aarnio
no flags Details | Diff
Here's the testcase, for posterity. (149 bytes, text/plain)
2001-03-13 05:46 EST, Tim Waugh
no flags Details
New version of TeXFOT-fix -- proper one, but incomplete (see comments) (2.62 KB, patch)
2001-03-13 15:14 EST, matti aarnio
no flags Details | Diff

  None (edit)
Description matti aarnio 2001-03-12 12:37:00 EST
The sourceforge logged OpenJade 1.3 bug is present at current RawHide
instance of OpenJade, and my 0.6 MB SGML input triggers it while building
TOC.

E.g. having section titles of:   $VARNAME/file.txt  translates
to TeX as:     \VARNAME/file.txt

which both  jadetex  and   pdfjadetex  barf at.
Suggested patch will probably work.
Comment 1 Tim Waugh 2001-03-12 16:33:49 EST
Could you please verify that the patch actually does work?  Thanks.
Comment 2 matti aarnio 2001-03-12 17:06:38 EST
we shall see, I constructed patch for it, and am now running 'rpm -bb' ..
My initial goal was to have OpenJade CVS version compiling at current
rawhide, but alas, that doesn't seem to be possible (autoconf/automake
feature problems.)
Comment 3 matti aarnio 2001-03-12 17:27:14 EST
Created attachment 12482 [details]
patch -p3
Comment 4 matti aarnio 2001-03-12 19:28:46 EST
ok, it works.  $MAILVAR/ appears successfully at TOC
of  http://zmailer.org/zman/zmanual.pdf
Comment 5 Tim Waugh 2001-03-13 05:08:36 EST
Your patch is different to the one on sourceforge.  The sourceforge version 
makes more sense to me.  Do you know why yours works?  Did you try the 
sourceforge (add a line) version before the replace-a-line version you've 
attached?

Comment 6 Tim Waugh 2001-03-13 05:46:55 EST
Created attachment 12567 [details]
Here's the testcase, for posterity.
Comment 7 matti aarnio 2001-03-13 05:59:27 EST
I went thru both the C++ code, and the resulting TeX output.
The problem lurks at place where code tries to store a character
in to string beyond its end.  That is why adding the extra char
(dummy) is needed.

Changeing the "protection string" into one with non-special starter ('?')
caused header title to be converted from:
      $XXX
to
      ?XXX
which naturally the TeX ate just fine.

The wrong result is not apparent at my output, as only top-level chapter
titles go to page headers, but it shows up at PDF bookmarks.
Comment 8 matti aarnio 2001-03-13 06:03:06 EST
Oh yes, sorry for the difference - my bug at reading that HTMLized patch..
Comment 9 matti aarnio 2001-03-13 07:26:59 EST
Reading more of the relevant C++ code, I think the bug is considerably bigger..

  Input:

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN" []>
<article>
<section>
<title> \ ^ _ ~ { } &amp; # % $ VARNAME</title>
<para>Words.</para>
</section>
</article>

  Produces (jade)TeX:
....
{title-sosofo-mode}}\char92{} \char94{} \char95{} \char126{} \{ \} \Entity{amp} 
\# \% \$ VARNAME\endNode{}\def\HeadingText{%
\ ^ _ ~ \{ \}  \# \% \$ VARNAME}%
\endHeadPar{}\endSeq{}
....

  Which contains parts of protected chars, and parts of NON-PROTECTED chars
  in the HeadingText block.

  The fix in question did help for chars
       { } # % % $
  but not for
       \ ^ _ ~
  (and &amp; - propably not any of entities, e.g.  &lt;  included..)

  More fixes are needed.
Comment 10 matti aarnio 2001-03-13 15:14:41 EST
Created attachment 12626 [details]
New version of TeXFOT-fix -- proper one, but incomplete (see comments)
Comment 11 matti aarnio 2001-03-13 15:21:21 EST
Proper Solution will need some way to insert arbitrary characters (at least
of codepoints <= 255) into TeX without it being a macro, but try as I might,
I don't seem to be able to find a way to do that.

Alternate would be to fix the  HYPERREF  package in tetex to allow:

Package hyperref Warning: Token not allowed in a PDFDocEncoded string,
(hyperref)                removing `\char' on input line 142.

No doubt it is something trivial and mentioned somewhere, but my TeXnical
skills are inadequate here...
Comment 12 Tim Waugh 2001-03-13 16:24:52 EST
Mine too.  openjade-1.3-13 has the one-line patch applied (the sourceforge 
version), so it's partially fixed there.

I don't think that Adam is planning any maintenance release for openjade 1.3.  
It might be worth checking if this is fixed in the current CVS.
Comment 13 matti aarnio 2001-03-13 18:38:34 EST
It isn't, and that is second bug I spotted with my quick overview...
- The new   inMath_   counter is mishandled at  endMathSeq
   (propably a feature that is not yet finalized..)
- protectedChar_ is initialized too short.

Otherwise the CVS version has fancy table changes, and ligature breaks
for  -, <, and > chars.
Comment 14 Tim Waugh 2001-03-20 06:56:02 EST
Care to whip up a quick patch?  I have CVS commit writes on openjade now. :-))
Comment 15 Tim Waugh 2001-08-08 06:35:13 EDT
Closing; the original bug is now fixed.  Please open a separate bug report 
with more details about the others that you found, if not already fixed.  And 
patches. ;-)

Note You need to log in before you can comment on or make changes to this bug.