Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.2.3

Request #6133 Add support for PDF rendering
Submitted: 2005-12-02 20:06 UTC
From: kevin_myer at iu13 dot org Assigned: delatbabel
Status: Assigned Package: Text_Wiki
PHP Version: 4.3.9 OS: Linux (RHEL)
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 16 - 4 = ?

 
 [2005-12-02 20:06 UTC] kevin_myer at iu13 dot org
Description: ------------ This would be an enhancement request to extend Text_Wiki so that it would render markup directly to PDF. A site could then provide an electronic version of text online, and use the PDF method to generate a document from the same base. There are scattered references to PDF in the Text_Wiki class documentation (under the $formatConf and $renderConf variable documentation), but I'm assuming those are simply examples of how the variables would be used if a PDF rendering option existed.

Comments

 [2006-02-22 12:22 UTC] delatbabel (Del)
There is a reason that this can't be done with the current Text_Wiki structure. The code around lines 958 - 968 of the current (CVS HEAD) revision of Wiki.php adds the non-parsed input to the end of the output string character by character when not in a delimited section. For general text-based renderers such as Wikitext, this makes sense, because if you are in a plain text section of the input, such as: ... this is some text ... ^ here then to process the output for the next 2 characters "x" and "t" then you would add them to the end of the output. Even for something like Xhtml it works, because the Xhtml version of "this is some text" is just those 2 characters longer than the Xhtml version of "this is some te". Anyone who knows the internal structure of PDF knows this isn't going to work, because PDF, like PostScript, is a token-suffix based language. So the PDF rendering of the first part of the text would look like: (this is some te) display ... and the PDF rendering of the whole text would look like: (this is some text) display (these are abstracted examples -- PDF is a binary format that doesn't quite work like this, but it shows part of the internal structure with the encoding cut away. PostScript is much the same as the above, however). So you can't just add the two characters "x" and "t" to the end of the rendering of "this is some te" to get the rendering of "this is some text". To fix this, it requires a re-structuring of the internal code of Text_Wiki, to move the render() method from the body of Wiki.php into the body of each of the rendering classes. I discussed this with p.m jones a while ago in email and there has been some reference to it on the text_wiki mailing list at tigris.org but at this stage it's probably going to involve a re-engineering of the class and migration to a new architecture (Text_Markup) before PDF or PostScript output is possible.
 [2006-02-23 04:37 UTC] toggg
I don't see why it's impossible to produce token-suffix with the current structure. There's plenty of means to do that, at least using the pre and post render. You can even quite "by-pass" the render() this way.
 [2006-02-23 05:04 UTC] justinpatrin
It should also be very possible to replace all plaintext with tokens as well. Something like: '/'.$wiki->token.'(\d+)'.$wiki->token.'([^'.$wiki->token.']*)/' replace with original token plus a new one for the text and '/([^'.$wiki->token.']*)'.$wiki->token.'(\d+)'.$wiki->token.'/' replace with new token for the text and original token plus a special case for if there are no tokens in the text (i.e. it's all plaintext).