You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Paul Dumais <pa...@unstate.ca> on 2006/02/18 01:05:56 UTC
FOP.91beta Spanning a page break
Hi,
I'm absolutely new to FOP. I have been checking out fop.91beta with docbook 5.0
and xsltproc. Everthing was fine untile I tried to write a task (procedure
nested within) that spanned more than one page (pdf output). When I try to
process such a long task/procedure I get:
Exception
java.lang.RuntimeException: Some content could not fit into a line/page after 50
attempts. Giving up to avoid an endless loop. (fo:block, location: 2/37967)
This only happens when the task/procedure is longer than a page. When shorter, I
get the output I would expect.
I have tried looking up the problem on Google and it seems that some problems
were the result of figures. However, I simply have a task, and a procedure with
a bunch of steps. Shouldn't the task/procedure have a page break inserted
automatically? Is this a problem with FOP or xsltproc?
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP.91beta Spanning a page break
Posted by Paul Dumais <pa...@unstate.ca>.
Hi Jeremias,
Thanks for the info. I tried inserting some docbook elements such as <?dbfo-need
height="2in" ?> and <?dbfo keep-together="auto" ?>. The first is supposed to put
in a page break if the "2in" condition is met (that is less than 2 inches remain
before the end of the page). The second element is supposed to relax the
keep-together property so that the procedure can be broken. Neither appear to
work for me. Should I take my problem to the docbook mailing list?
Here is the docbook 5.0 article (task/procedure) that I am trying to output to
pdf using fop .91beta:
<!--@+leo-ver=4-thin-->
<!--@+node:paul.20060217090820:@thin protocols/misc/test.xml-->
<!-...@color-->
<!--@@language html-->
<!-...@nowrap-->
<article xmlns="http://docbook.org/ns/docbook" version="5.0" xml:lang="en">
<title>WaterJet Protocol</title>
<!--@ << Task >>-->
<!--@+node:paul.20060217093550:<< Task >>-->
<task>
<title>Drill or Cut Holes in Glass</title>
<!--@ << Procedure >>-->
<!--@+node:paul.20060217090820.2:<< Procedure >>-->
<procedure>
<step>
<para>Presuming that you already have a file drawn in L-edit,
you will need to convert only the needed information from .tdb
format to .dxf format. At present, we have software that will do
this conversion for holes only. There is also software in the
Nanofab that will convert a .gds file into a .dxf file. This
will work for both holes and polygons (for dicing lines).
</para>
</step>
<step>
<para>Save a copy of your L-edit design file with a new name.
You should have the holes and lines to be cut drawn on a
separate layer. Hide all layers except the one just mentioned
and the one that shows the outline of your wafer/substrate
(usually icon/outline). Move all the remaining objects so that
the origin of the coordinate system is at the lower left hand
corner of your substrate. Make sure that the mask that was made
from this L-Edit file was printed chrome side down. If it was
printed chrome side up, then your hole pattern will be a mirror
about the vertical center line with respect to the patterned
substrates. In this case, you will need to modify your drawing
by mirroring it about the same axis. Note that the WaterJet
software does not properly compensate for the actual hole
diameter that will be drilled due to factors such as abrasive
type, tube type, hole diameter, plate thicknesses and drill
speed. Therefore, the hole size specified in the .dxf file needs
to be smaller than the desired size. This size reduction depends
on the factors listed above and is so far a matter of experience
and trial and error. For drilling a single 1.1mm borofloat glass
plate bonded with a 0.5 mm 0211 glass plate, and a desired hole
diameter of 2 mm, medium abrasive, medium-low power/pressure
(and other factors that the operator finds suitable), the
specified diameter needs to be 1.1 or 1.15 mm. These parameters
should also hold for drilling similar holes in 1.1 mm borofloat
plates bonded together with 2mm thick plate glass. The above is
just for your information, always get the proper specification
from Herb Dexel prior to to drilling, and check the diameter
drilled on your first plate to make sure your first guess was
suitable, adjust as required.
</para>
</step>
<step>
<para>Select all the holes and change the radius to reflect the
needed reduction as given to you (see above).
</para>
</step>
<step>
<para>Select all objects (substrate outline, holes, cut lines)
and select cell...flatten from the L-edit menu. Save the
document. Select file...Export Mask Data...Cif and save the .cif
file to a directory that you can easily find when you later use
the ssh client to transfer it to gaea (one of our Linux
servers).
</para>
</step>
<step>
<para>
Open the ssh Secure Client Shell. Login to gaea. Navigate to:
/home/Archive/Software/Students/paul/WaterJet/Code. There are
two important files here: Cift and README. README contains the
simple instructions on how to operate the software. Cift is the
program that you run on gaea to convert the holes on your .cif
drawing to holes on specified in a .dxf drawing. Move your .cif
file to this directory (click on the new file transfer window
icon to open the secure file transfer client).
</para>
</step>
<step>
<para>
In the SSH secure shell, type ./Cift . This will start a the
menu-driven program. Press 1, < Enter>. Type or paste in
the file name of the .cif file you want to convert. Press <
Enter>. Press < Enter> again. Press 3, < Enter>.
This will write your file to output.dxf. Press < Enter>
again. Press q, < Enter> to quit.
</para>
</step>
<step>
<para>
Using the SSH Secure File Transfer client as before, move
output.dxf back to the directory that contains the original .cif
file. Open the .dxf file in an appropriate editor (Rhinoceros
works). Make sure all the holes are there and make sure that the
zero of your coordinate system is at the bottom left of the
substrate.
</para>
</step>
<step>
<para>
In this same editor, draw in any linear cuts that need to be
made. Save the file and send a copy to the WaterJet operator via
a 3.5” floppy.
</para>
</step>
<step>
<para>
Using Crystalbond 590 (brown stick), bond one glass substrate to
a sacrificial glass plate (usually cheap plate glass as thin as
possible ~2mm). In the case of borofloat where you want to bond
only the non-tin sides, make sure that you scribe the word 'Tin'
on the side that is marked with a 'T' with permanent marker. Use
a clean wipe and acetone to check which side of the glass this
'T' is written on. This 'T' should be removed and with acetone
after 'Tin' has been scribed onto the tin side with a diamond
scribe. Using a hot plate (preferably a digitally controlled
one) set the temperature to 150 degrees C. Place aluminum foil
onto the plate (so as not to dirty the hot plate) once this
temperature has been reached.
</para>
</step>
</procedure>
<!--@-node:paul.20060217090820.2:<< Procedure >>-->
<!-...@nl-->
</task>
<!-...@nonl-->
<!--@-node:paul.20060217093550:<< Task >>-->
<!-...@nl-->
</article>
<!-...@nonl-->
<!--@-node:paul.20060217090820:@thin protocols/misc/test.xml-->
<!-...@-leo-->
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP.91beta Spanning a page break
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
If this happens, this is most likely due to certain properties that
cause FOP to look at a section as one non-dividable part (keep-*
properties). One of those parts seems to be bigger in height than the
available height on one page. FOP is not able to fit that part into a
page even after trying to place the part on a subsequent page in the
hope that one of the subsequent pages will have more available height to
fit the part in. That's when this exception happens. So, it's not
strictly a FOP problem (but a feature, i.e. to detect layout problems).
It's certainly not an xsltproc problem. But.....FOP doesn't yet
implement the finer aspects of the keep properties that allow the keep
rules to be relaxed in certain conditions. What you should do is go on
the look-out for keep properties (or what triggers them through the
DocBook stylesheets) and see if you can find a solution to make the
"task" breakable in the desired places.
I hope that helps. If not, post or link to an example that we can run
ourselves to get better feedback.
On 18.02.2006 01:05:56 Paul Dumais wrote:
> Hi,
>
> I'm absolutely new to FOP. I have been checking out fop.91beta with docbook 5.0
> and xsltproc. Everthing was fine untile I tried to write a task (procedure
> nested within) that spanned more than one page (pdf output). When I try to
> process such a long task/procedure I get:
>
> Exception
> java.lang.RuntimeException: Some content could not fit into a line/page after 50
> attempts. Giving up to avoid an endless loop. (fo:block, location: 2/37967)
>
> This only happens when the task/procedure is longer than a page. When shorter, I
> get the output I would expect.
> I have tried looking up the problem on Google and it seems that some problems
> were the result of figures. However, I simply have a task, and a procedure with
> a bunch of steps. Shouldn't the task/procedure have a page break inserted
> automatically? Is this a problem with FOP or xsltproc?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org