styler 5.3 m110 pageset problem

[naglists]

stylersheet was working fine yesterday. today, crashy boing boing.

When I'm composing locally (peservices=off), Styler hangs. If I "kill" it,
it fails the composition and displays a DVI exception (opening dvi file
(filename) dvipos: -1 code 1 can't open dvi file, failure post-processing
for compser type pdf.

If I delete US Frontpage Set pageset, it's fine.
If I recreate US Frontpage Set by creating a copy of US Bodypage Set, it's
fine.
If I assign TOC, LOF, LOT, or Preface to trigger US Frontpage Set (or US
Bodypage Set) it fails again.

What is up?

--
Paul Nagai

[ebenton]

With Print Composer, doing Print Preview creates a DVI file, which is the file that is actually being viewed during Print Preview. Sometimes this will expose errors that you can't find during regular PDF processing. I'm not familiar with what goes on in PE and/or Styler, but what happens when you do a Print Preview?

Or you might try set crashyboingboing=off.

[naglists]

I'm presently ignoring the problem which may be related to a specific test
document. I gotta get the formatting work done, then I'll come back and
start chopping up my test doc.

That said, I am doing Print Composer runs (not Print Previews, but the
results may be the same ... I am definitely seeing .dvi leftovers in
.aptcache) during development. I will typically post the .style to PE and
test it in that environment toward the end or when I need authors to review
with author-eyes.

Ok, I just did two print previews and two PDF compositions using the old and
new "test documents" and all is well. Hmmm. Either I've unknowingly scrubbed
whatever was hinky in the .style, the gremlins are bugging someone else
today, or they're planning a fashionably late arrival. I did reboot a couple
of times yesterday ... that didn't fix it then. I also got Clay's favorite
failure (Crash within a Crash) at one point.

Ah well ...

[ptc-953343]

I had a similar dvi error reporting - no information to help troubleshoot.
If I read your post right it seems the opposite of what I had difficulties
with. My situation was that it work with Print composer (local engine) but
would not work with PE.

After packaging everything up and sending it in, it turned out to be
related to the content. For me the issue was missing graphics. I had a
reference to a file that didn't exist. Evidently Composer and PE react
differently to the problem. Where Composer reported the problem and
carried on, PE would kick back an error that looked similar to yours and
would fail.

Maybe some one restored a file on you?

..dan

> I'm presently ignoring the problem which may be related to a specific test
> document. I gotta get the formatting work done, then I'll come back and
> start chopping up my test doc.
>
> That said, I am doing Print Composer runs (not Print Previews, but the
> results may be the same ... I am definitely seeing .dvi leftovers in
> .aptcache) during development. I will typically post the .style to PE and
> test it in that environment toward the end or when I need authors to
> review
> with author-eyes.
>
> Ok, I just did two print previews and two PDF compositions using the old
> and
> new "test documents" and all is well. Hmmm. Either I've unknowingly
> scrubbed
> whatever was hinky in the .style, the gremlins are bugging someone else
> today, or they're planning a fashionably late arrival. I did reboot a
> couple
> of times yesterday ... that didn't fix it then. I also got Clay's favorite
> failure (Crash within a Crash) at one point.
>
> Ah well ...
>
> On Thu, Jun 17, 2010 at 4:10 AM, Benton, Ed L <->
> wrote:
>
>> With Print Composer, doing Print Preview creates a DVI file, which is
>> the
>> file that is actually being viewed during Print Preview. Sometimes this
>> will expose errors that you can?t find during regular PDF processing.
>> I?m
>> not familiar with what goes on in PE and/or Styler, but what happens
>> when
>> you do a Print Preview?
>>
>>
>>
>> Or you might try set crashyboingboing=off.
>>
>>
>>
>> *From:* Paul Nagai [
>> it,
>> it fails the composition and displays a DVI exception (opening dvi file
>> (filename) dvipos...

[steve.thompson4]

Also recently had a similar problem. Print Preview allowed me to see the page where it failed. That led to discovery of two unintentionally contiguous <brk> tags (used to force a new page).

Why that was causing the Compose PDF to fail, I do not know, but removal of one allowed the file to process normally.

Just FYI...
Steve Thompson
+1(316)977-0515

[naglists]

Thanks, everyone. I got it. Or at least I reproduced / fixed / reproduced
the same sort of hang / dvi failure. I assume the earlier problem was
something similar.

Edit Source (so, yeah, MY fault 😉

In this most recent case, I was referencing a string variable not
instantiated in the location I was calling it from.

Specific example: I am tweaking my List of Tables. If I am editing source
for title in chapter, this is legal to include in a savetext:
cnt__chapter.txt,\-\,num__table.txt

If I am in title in appendix, it has to be this, instead:
cnt__appendix.txt,\-\,num__table.txt

The former causes the failure if included in context of an appendix.

Obviously I don't expect the output I meant not the output I coded 😉 but
a hang/dvi error isn't helpful. Of course, I should really upgrade and get
rid of all my edit source code that I can. I will, I will. It's on my ToDo
list scheduled for Real Soon Now.


On Thu, Jun 17, 2010 at 12:04 PM, EXT-Thompson, Steve <
steve.thompson2@boeing.com> wrote:

> Also recently had a similar problem. Print Preview allowed me to see the
> page where it failed. That led to discovery of two unintentionally
> contiguous <brk> tags (used to force a new page).
>
> Why that was causing the Compose PDF to fail, I do not know, but removal of
> one allowed the file to process normally.
>
> Just FYI...
> Steve Thompson
> +1(316)977-0515
>

[naglists]

New wrinkle: Publishing Engine publishes without complaint despite Print
Compose doing the hang / DVI failure. Interesting. I'm doing my formatting
work on ever smaller test files before posting my stylersheet to the server
for runs at longer, more complex, "problem for my Styler Edit Source hacks
containing" files.