workingwiki-users

[ww-users] oops

[Peter L. R. <pl...@st...>]

OK, it is due to my not understanding something.  Deleting a line in
the makefile made the problem dissappear.  Now my question is why having 

debug-nup.pdf: debug-page.latex.pdf
	pdfnup  --nup 2x1 --outfile $@ $^

in the makefile should cause it to use pdflatex rather than latex?

I'm still having the same problem in an actual project, and can't find
anything that might be telling it to use pdflatex.  In fact the string
"pdf" doesn't appear in the page with the latex on it, or any of the
makefiles associated with the project.

???, peter.

Re: [ww-users] oops

[Lee W. <wor...@gm...>]

I've looked in (my copy of) the WW makefiles.  It does seem to be 
somewhat wrong, but I'm not sure about this followup issue.  I don't 
think this line should have any effect on how latexml runs.

WorkingWiki's makefiles handle dependencies in .tex files by making an 
auxiliary makefile "document.d" for each file "document.tex".  There are 
three relevant lines there.  If document.tex contains 
\includegraphics{figure} document.d will contain:

document.pdf document.latex.pdf : figure.eps

because if we run latex it will look for figure.eps [document.pdf is 
made using latex, the same as document.latex.pdf].  Next

document.pdflatex.pdf document.xelatex.pdf : figure.pdf

because pdflatex and xelatex will look for figure.pdf.

Then for latexml:

document.latexml.xhtml document.latexml.html : figure.pdf

This seems to be the problem.  As you say, latex is the default, so why 
not put figure.eps here?  As far as I can see from the latexml source, 
it will accept eps, png, pdf, and various other file types here - I 
don't know in what order of precedence.

I seem to have three options:

make document.latexml.* depend on figure.pdf, as we have now
   This works when the document is written for pdflatex, and fails when 
it's written for latex.  "Fails" means it refuses to run latexml because 
it can't make figure.pdf, even though figure.eps is provided and would 
work fine.

make it depend on figure.eps instead
   This works on documents written for latex and fails if the document 
is written for pdflatex.

make it not depend on either
   In this case, it won't refuse to run latexml outright when the guess 
is wrong about which file to look for.  Unfortunately, there will be 
times when the figure is updated - or when the figure wasn't there but 
now you've uploaded it - and it won't rerun latexml.

I'll change to not depending on either, but if anyone has a better idea 
I'm interested.  Thank you for the report.  If I've misunderstood and 
you are actually reporting a failure to make a .pdf file, not a .xhtml 
file, let me know.

Lee

On 06/15/11 09:12, Peter L. Ralph wrote:
> OK, it is due to my not understanding something.  Deleting a line in
> the makefile made the problem dissappear.  Now my question is why having
>
> debug-nup.pdf: debug-page.latex.pdf
> 	pdfnup  --nup 2x1 --outfile $@ $^
>
> in the makefile should cause it to use pdflatex rather than latex?
>
> I'm still having the same problem in an actual project, and can't find
> anything that might be telling it to use pdflatex.  In fact the string
> "pdf" doesn't appear in the page with the latex on it, or any of the
> makefiles associated with the project.
>
> ???, peter.
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] oops

[Peter L. R. <pl...@st...>]

Ooops, meant to reply to the list earlier.

> seems to me that if latex and latexml accept png and jpg files I should  
> strive to have makefile rules that don't make you jump through  
> unnecessary hoops
>
>> I have not committed the change you mention.  Er, I appreciate the work,
>> but perhaps you were too hasty?  It seems to me that it is better to
>> have changes in figures noticed than the alternative?  Either way we go,
>> I forsee some documentation.
>
> I decided it's better to miss some dependencies sometimes than to  
> completely crash and refuse to make the output sometimes - the latter  
> condition can hurt people when they're on a paper submission deadline  
> and the like.  So I made the choice independently of whether it actually  
> relates to the problem you had...

I agree; but I can also imagine the case when, under a deadline, someone
has to figure out why their figure isn't updating in their paper.  The
unnecessary hoops are better, in that case, because they give an error
message, and tell you what to do to fix it, even if it is annoying.

But, perhaps Jonathan's (magic) solution will work?  

-p

Re: [ww-users] oops

[Lee W. <wor...@gm...>]

On 06/16/11 21:11, Peter L. Ralph wrote:
> Ooops, meant to reply to the list earlier.

I should have too.

>> seems to me that if latex and latexml accept png and jpg files I should
>> strive to have makefile rules that don't make you jump through
>> unnecessary hoops
>>
>>> I have not committed the change you mention.  Er, I appreciate the work,
>>> but perhaps you were too hasty?  It seems to me that it is better to
>>> have changes in figures noticed than the alternative?  Either way we go,
>>> I forsee some documentation.
>>
>> I decided it's better to miss some dependencies sometimes than to
>> completely crash and refuse to make the output sometimes - the latter
>> condition can hurt people when they're on a paper submission deadline
>> and the like.  So I made the choice independently of whether it actually
>> relates to the problem you had...
>
> I agree; but I can also imagine the case when, under a deadline, someone
> has to figure out why their figure isn't updating in their paper.  The
> unnecessary hoops are better, in that case, because they give an error
> message, and tell you what to do to fix it, even if it is annoying.

Of course, it's best if it works right.  But if the paper isn't updating 
you can make it update by using the "sync all source files" action, or 
by just making a trivial edit in the .tex file.  If it refuses to give 
you the output 5 minutes before you leave for the airport it's a real 
problem.

> But, perhaps Jonathan's (magic) solution will work?

Yes.  For anyone who's wondering, Jonathan's proposal is on the bug 
tracker:
https://sourceforge.net/tracker/index.php?func=detail&aid=3317645&group_id=366300&atid=1527385

lw

> -p
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] oops

[Jonathan D. <du...@mc...>]

Not to deny that this should be addressed, but an easy, robust way
around it is to specify figure extensions (ie.,
\includegraphics{figure.eps}).  I've been doing it this way even since
before WW.

JD

On Fri, Jun 17, 2011 at 12:35 AM, Lee Worden <wor...@gm...> wrote:
> On 06/16/11 21:11, Peter L. Ralph wrote:
>> Ooops, meant to reply to the list earlier.

> I should have too.

>>> seems to me that if latex and latexml accept png and jpg files I should
>>> strive to have makefile rules that don't make you jump through
>>> unnecessary hoops

>>>> I have not committed the change you mention.  Er, I appreciate the work,
>>>> but perhaps you were too hasty?  It seems to me that it is better to
>>>> have changes in figures noticed than the alternative?  Either way we go,
>>>> I forsee some documentation.

>>> I decided it's better to miss some dependencies sometimes than to
>>> completely crash and refuse to make the output sometimes - the latter
>>> condition can hurt people when they're on a paper submission deadline
>>> and the like.  So I made the choice independently of whether it actually
>>> relates to the problem you had...

>> I agree; but I can also imagine the case when, under a deadline, someone
>> has to figure out why their figure isn't updating in their paper.  The
>> unnecessary hoops are better, in that case, because they give an error
>> message, and tell you what to do to fix it, even if it is annoying.

> Of course, it's best if it works right.  But if the paper isn't updating
> you can make it update by using the "sync all source files" action, or
> by just making a trivial edit in the .tex file.  If it refuses to give
> you the output 5 minutes before you leave for the airport it's a real
> problem.

>> But, perhaps Jonathan's (magic) solution will work?

> Yes.  For anyone who's wondering, Jonathan's proposal is on the bug
> tracker:
> https://sourceforge.net/tracker/index.php?func=detail&aid=3317645&group_id=366300&atid=1527385

> lw

>> -p

>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users