Bug 31525 - openjade-1.3 has known (SourceForge) bug with a fix
Summary: openjade-1.3 has known (SourceForge) bug with a fix
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: openjade   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Brock Organ
URL: http://sourceforge.net/tracker/index....
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-12 17:37 UTC by matti aarnio
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-14 13:49:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 22:27 UTC, matti aarnio
no flags Details | Diff
Here's the testcase, for posterity. (149 bytes, text/plain)
2001-03-13 10:46 UTC, Tim Waugh
no flags Details
New version of TeXFOT-fix -- proper one, but incomplete (see comments) (2.62 KB, patch)
2001-03-13 20:14 UTC, matti aarnio
no flags Details | Diff

Description matti aarnio 2001-03-12 17:37:00 UTC
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

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 21:33:49 UTC
Could you please verify that the patch actually does work?  Thanks.

Comment 2 matti aarnio 2001-03-12 22:06:38 UTC
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 22:27:14 UTC
Created attachment 12482 [details]
patch -p3

Comment 4 matti aarnio 2001-03-13 00:28:46 UTC
ok, it works.  $MAILVAR/ appears successfully at TOC
of  http://zmailer.org/zman/zmanual.pdf

Comment 5 Tim Waugh 2001-03-13 10:08:36 UTC
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 

Comment 6 Tim Waugh 2001-03-13 10:46:55 UTC
Created attachment 12567 [details]
Here's the testcase, for posterity.

Comment 7 matti aarnio 2001-03-13 10:59:27 UTC
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:
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 11:03:06 UTC
Oh yes, sorry for the difference - my bug at reading that HTMLized patch..

Comment 9 matti aarnio 2001-03-13 12:26:59 UTC
Reading more of the relevant C++ code, I think the bug is considerably bigger..


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

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

  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 20:14:41 UTC
Created attachment 12626 [details]
New version of TeXFOT-fix -- proper one, but incomplete (see comments)

Comment 11 matti aarnio 2001-03-13 20:21:21 UTC
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 21:24:52 UTC
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 23:38:34 UTC
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 11:56:02 UTC
Care to whip up a quick patch?  I have CVS commit writes on openjade now. :-))

Comment 15 Tim Waugh 2001-08-08 10:35:13 UTC
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.