User talk:Austin J. Che/Extensions/LatexDoc

From OpenWetWare

< User talk:Austin J. Che | Extensions
Revision as of 15:43, 6 August 2008 by Peter Staab (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
  • Reshma 19:40, 29 January 2007 (EST): The main obnoxious thing about composing latex docs on the wiki is that it doesn't wrap "plain text". It wraps in the edit window but the html page has one line per paragraph unless you manually include returns.
  • Austin Che 19:43, 29 January 2007 (EST): actually I recently changed this behavior at the request of someone. The original behavior would treat most of the text as normal html and thus wrap in the browser. However, due to mediawiki parsing, it would insert pre tags such that any lines that began with a space would be boxed which looked weird. So I put one pre around the entire document instead. If there's an alternative, I'd be happy to implement it.
  • Austin Che 21:21, 29 January 2007 (EST): Ok, I added an auto word wrap to it. Check it out.
  • Reshma 21:20, 30 January 2007 (EST): EPS files are not permitted. This is unfortunate since I seem to have better luck with EPS files when writing "normal" latex docs.
  • Reshma 21:20, 30 January 2007 (EST): Errors in the latex document (i.e. syntax errors) cause Firefox to crash on Mac OS X 10.3. However, this does not happen in Safari in Mac OS X 10.4.
  • Austin Che 23:17, 30 January 2007 (EST): Currently it uses pdflatex which I find more useful. It would be trivial to make it generate pdf via latex->dvipdf or latex->dvips->ps2pdf. But making 3 buttons called 'get PDF via ...' seemed silly but I guess I could do it. Regarding syntax errors, that seems unbelievable that firefox would crash. When does it crash? Looking at the latex document? That's just plain text for the browser and I don't see how that could do anything. When getting the pdf? If there's a syntax error, no pdf should be generated at all but even if an incorrect pdf was generated, it should have nothing to do with the browser at all, and would have to do with the pdf viewer.
  • Reshma 00:08, 31 January 2007 (EST): I see your point about it being silly to have 3 get pdf buttons. I guess the only reason to do this is it might facilitate reuse of the same images when going between offline and onlike latex documents. As for the syntax errors crashing Firefox, the crashes do happen when generating/getting the pdf. It may very well be a problem with the pdf viewer. I just thought I would note that it is happening here on the talk page.

Contents

Version page broken under 1.8

SpecialVersion.php gives the following error.

Catchable fatal error: Object of class LatexDoc could not be converted to string in /mywiki/includes/SpecialVersion.php on line 241

Is this happening when it parses the extension credits? I am running MW 1.8. --Jacobs 16:11, 20 May 2007 (EDT)

  • Austin Che 22:16, 20 May 2007 (EDT): I made a small change (untested). Either download it or add function __toString() { return 'LatexDoc'; } to the LatexDoc class. See if that fixes your problem.
  • Jacobs 10:27, 22 May 2007 (EDT): Works perfectly! Thanks.
  • Jacobs 11:08, 22 May 2007 (EDT):My collaborators requested the ability to easily grab the latex source so I added a "Export Source" link that gets the raw wiki. The only ugly bit is that when the browser parses the url its getting it looks for file extensions of type *.xxx so it tells the user it is downloading index.php. Not sure how to fix that.
//in function onParserBeforeStrip()
//...
      //add "Export Source" link
      $sk->makeKnownLinkObj( $parser->mTitle, wfMsg( 'latexdoc_get_source' ),  
               'action=raw&ctype=application/x-tex&filename=wiki_latex_source.tex' );

//and in wfLatexDocInit()
//....
    $wgMessageCache->addMessages( array(
                                        'latexdoc_invalid_filename' => 'Filename $1 is invalid',
                                        'latexdoc_no_page' => 'Wiki page $1 does not exist',
                                        'latexdoc_no_text' => 'Article contains no text, cannot generate output',
                                        'latexdoc_cant_create_dir' => 'Cannot create temporary directory $1',
                                        'latexdoc_cant_write' => 'Cannot write to file $1',
                                        'latexdoc_error' => "LaTeX error:<br />\n\n$1",
                                        'latexdoc_get_pdf' => 'Get PDF',
                                        'latexdoc_get_log' => 'Get log',
                                        'latexdoc_get_pdf_no_cache' => 'Regenerate PDF',
                                        'latexdoc_get_source' => 'Export Source',
                                        ));

  • Austin Che 17:13, 22 May 2007 (EDT): thanks. Note from my reading of RawPage.php, it seems that
    ctype=application/x-tex&filename=wiki_latex_source.tex
    does nothing. You can't change the ctype to something other than a very restricted set of types and you can't set the filename (at least on OWW's version of mediawiki). Let me know if those parameters do something for you under MW1.8.

List of included files

A very nice feature would be a list of the included files that the script found. Maybe using the wiki thumbnail functions. This is one I can't whip out in 20 minutes but maybe you could Austin? If not I will look at it more closely myself.

Thanks! Jacobs 17:21, 3 January 2008 (CST)

  • Austin Che 17:56, 3 January 2008 (CST): I doubt this would be a 20 minute fix for me. Getting the list of included files is easy. Just add something inside the foreach loop of getHelperFiles. The question is where and how you want to display that information.
  • Jacobs 13:52, 4 January 2008 (CST):I could do the display part but I dont know the MW hooks or how to hand off the list to the rendering part of the code. I will take a look.
  • Jacobs 16:38, 4 January 2008 (CST):Here is a modified "onParserBeforeStrip" that lists the included files. Basically it just runs the pregmatch before the $text gets stripped and then tacks on a list after the text has been strip marked. The list is just floated to the right and designed to stand out over the <pre> box.


Aside:Is there a guide to Mediawiki internals anywhere?!?! Austin, how did you find out about the ParseBeforeStrip? Did you know enough to go to includes/Parser.php and look for something like that? <syntax type="php" file="http://ssel.montana.edu/~jacobs/LatexDoc_onParserBeforeStrip.php">Source file could not be found</syntax>

  • Austin Che 09:27, 5 January 2008 (CST): Neat. I'll add your changes in. Check out Mediawiki hooks for the list of internal hooks. Ok, your changes are in. The formatting however is really strange. See OpenWetWare:Feature_test/LatexDoc.
  • Jacobs 09:51, 7 January 2008 (CST):Fixed. Images show up as 100px thumbs.
  • Austin Che 13:51, 7 January 2008 (CST): I haven't tried the code but it doesn't seem like it would work for non-images also.

mediawiki 1.12

  • Tore Birkeland 15:59, 28 April 2008 (EDT): latexdoc does not work properly with version 1.12, as the Image class has been removed for some reason. A fix is to use wfFindFile() instead of new Image() on line 206, and image->getPath() instead of image->getImagePath on line 213.

<syntax type="php"> 201 $title = Title::newFromText($page); 202 if ($title) 203 { 204 if ($title->getNamespace() == NS_IMAGE) 205 { 206 $image = wfFindFile($title); 207 if (! $image->exists()) 208 { 209 $wgOut->addWikiText(wfMsg('latexdoc_no_page', $page)); 210 return false; 211 } 212 213 if (! copy ($image->getPath(), $outfile)) 214 { 215 $wgOut->addWikiText( wfMsg( 'latexdoc_cant_write', "$outfile" ) ); 216 return false; 217 } 218 continue; 219 } 220 221 $rev = Revision::newFromTitle($title); 222 } </syntax>

  • Austin Che 16:28, 28 April 2008 (EDT): Thank you very much Tore! I was aware that this was a problem with the newer mediawiki but haven't had time to find a fix for it.

LatexDoc broken?

  • DAD 14:04, 6 July 2008 (UTC): Hi -- I'm interested in using LatexDoc, but the current demo OpenWetWare:Feature_test/LatexDoc appears to be broken. As far as I can tell from reading the log, the pdf gets created, but doesn't get displayed.
  • Austin Che 14:12, 6 July 2008 (UTC): Hi, thanks. LaTeX wasn't installed when OWW moved servers. It's now working again.
  • DAD 15:31, 6 July 2008 (UTC): Thanks!

Permissions for working directory

Hi, I am trying to get LatexDoc to work on a personal server. I have successfully added LatexDoc.php to the extensions of Mediawiki, created a new page with some LaTeX and upon saving get the standard buttons at the top of the page, so I think I have successfully installed mediawiki and latexdoc. However, when I click either "Get PDF" or "Regenerate PDF" I get the following error:

Warning: fopen(ltd_baf2c656a942c9d8e678f4dac6197ddd.tex) [function.fopen]: failed to open stream: Permission denied in /var/lib/mediawiki/extensions/LatexDoc.php on line 252.

I'm sure its a permissions problem. I have a ubuntu 8.04 server and have made the working directory for LatexDoc "/var/lib/mediawiki" (which I'm not sure is the best). The permissions on the subdiretories image and image/latexdoc are

drwxr-xr-x 3 www-data www-data 4096 2008-07-25 09:41 images

Any thoughts?

  • Austin Che 20:07, 25 July 2008 (UTC): I'm not sure what you mean by changing the working directory, but it seems like you should just not set the working directory at all and it should work.
  • Peter Staab 17:10, 6 August 2008 (UTC):I removed the setting of the working directory and now get the error:

The requested URL /images/latexdoc/ltd_baf2c656a942c9d8e678f4dac6197ddd.pdf was not found on this server.

However, looking directly at the server this page is located at:

/images/latexdoc/ltd_baf2c656a942c9d8e678f4dac6197ddd.pdf

  • Austin Che 17:42, 6 August 2008 (UTC): I don't understand this error. "The requested URL /images/latexdoc/ltd_baf2c656a942c9d8e678f4dac6197ddd.pdf was not found on this server." is an error from your browser? But you say you can directly access the url /images/latexdoc/ltd_baf2c656a942c9d8e678f4dac6197ddd.pdf (i.e. paste it into the browser)?
  • Peter Staab 18:25, 6 August 2008 (UTC): I'm sorry, the one I can access is:

/mediawiki/images/latexdoc/ltd_baf2c656a942c9d8e678f4dac6197ddd.pdf

  • Austin Che 18:48, 6 August 2008 (UTC): This shouldn't be a problem. Are normal mediawiki images working for you? Make sure $wgScriptPath = "/mediawiki" and $wgUploadPath = "$wgScriptPath/images" in LocalSettings.php.
  • Peter Staab 20:09, 6 August 2008 (UTC): $wgScriptPath = "/mediawiki" was already set in LocalSettings.php, and there was no line $wgUploadPath = "$wgScriptPath/images" in LocalSettings.php, so I added it, however, there does not appear to be any difference so far.

Just one other comment, the "Get Log" link also doesn't point to the right file.

  • Austin Che 20:21, 6 August 2008 (UTC): If your image uploads work, there's no reason this won't. You can try specifically setting $wgLatexDoc->workingPath="/mediawiki/images/latexdoc"
  • Peter Staab 20:43, 6 August 2008 (UTC): That works. It's odd that the workingDir variable didn't seem to work, but this did. Thanks for all your help Austin. I'm looking forward to using this now.
Personal tools