Seifeddine Dridi wrote:
> Does anybody know why it isn’t allowed to set borders in page regions ? The
> XSL specs says that border-width and padding values must be 0, but I don’t
> understand why it is enforcing this restriction, RenderX for instance allows
> borders in page regions.
You can acti
[
https://issues.apache.org/jira/browse/FOP-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Furini resolved FOP-2441.
--
Resolution: Duplicate
Fix Version/s: trunk
Assignee: Luca Furini
As Thanasis Giannimaras
[
https://issues.apache.org/jira/browse/FOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Furini resolved FOP-2348.
--
Resolution: Fixed
Fix Version/s: trunk
Patch applied in revision r1655099
Revision r1659776
[
https://issues.apache.org/jira/browse/FOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Furini reassigned FOP-2348:
Assignee: Luca Furini
> [PATCH] PDF File Attachment Extension is bro
Now that I'm back in harness, thanks to a lot of patient people, I
only need the magical power to work on JIRA issues in order to be a
(somewhat) useful committer.
Glen, as I'm told you are FOP's JIRA administrator, could you please
give the necessary privileges to my "lfurini" JIRA account? Do yo
Luis Bernardo wrote:
> I am under the impression that committership rights are never revoked but I
> could be wrong. Are you sure that you can log in to your Apache account?
> Maybe a year ago or so Apache forced a change in passwords. Did you change
> your password when that happened?
Yes, I rem
[
https://issues.apache.org/jira/browse/FOP-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Furini updated FOP-2441:
-
Attachment: change.diff
Proposed patch
> pdf:embedded-file extension is broken, gives NullPointerExcept
[
https://issues.apache.org/jira/browse/FOP-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Furini updated FOP-2441:
-
Attachment: test_attachment.fo
Simple fo file to reproduce the error
> pdf:embedded-file extension
Luca Furini created FOP-2441:
Summary: pdf:embedded-file extension is broken, gives
NullPointerException
Key: FOP-2441
URL: https://issues.apache.org/jira/browse/FOP-2441
Project: Fop
Issue
On Fri, Jul 4, 2008 at 6:09 PM, Andreas Delmelle
<[EMAIL PROTECTED]> wrote:
> Now, I'm wondering... In theory, it should not be too difficult to get at
> this info, since ultimately it is also needed when computing 'top' or 'left'
> if they are specified as a percentage. In that case, the value is
On Wed, Jul 2, 2008 at 8:24 PM, Andreas Delmelle
<[EMAIL PROTECTED]> wrote:
> If you have the area's own dimensions, and the complement properties
> (bottom-right), is that not enough?
>
> For the renderer:
> -> top = (bottom - area-bpd - borders - padding))
> -> left = (right - area-bpd - borders
(it's still me, I just subscribed with the gmail account I use more
frequently, to avoid problems of messages not reaching the list ...)
On Wed, Jul 2, 2008 at 8:24 PM, Andreas Delmelle
<[EMAIL PROTECTED]> wrote:
> If you have the area's own dimensions, and the complement properties
> (bottom-rig
(I'm re-posting this message as I sent it yesterday and still cannot see
it in the list archives, I hope I'm not duplicating it unnecessarily)
On Mon, Jun 23, 2008 at 5:12 PM, Luca Furini <[EMAIL PROTECTED]> wrote:
If there is a block-container with both width and height set,
While playing a bit with absolute positioned block container, I think
I stumbled into a little bug.
If there is a block-container with both width and height set, its
position can be correctly controlled using top and left (and indeed
there are many testcases checking that) but bottom and right do
On Thu, Jun 19, 2008 at 3:45 PM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> There's both in FOP. block-container has the border on the viewport.
> table-cell has it on the reference area (table-cell doesn't generate a
> viewport). But I fear we might actually be wrong about having the border
> a
On Thu, Jun 19, 2008 at 1:26 PM, Luca Furini <[EMAIL PROTECTED]> wrote:
> "Only a reference-area may have a block-progression-direction which is
> different from that of its parent."
Ops, I realize only now that it says "direction" and not "dimension"
Some time ago (well, almost 2 years!) we spoke about the possibility
to allow users to define borders and padding for the page regions [1].
This week I finally found some time to do it, so I have it working on
my local copy ... but then I was struck by a dilemma: the additional
traits about border
On Mon, Jun 16, 2008 at 4:52 PM, <[EMAIL PROTECTED]> wrote:
> Fixing the PageBreakingAlgorithm, replacing calls to getLineWidth() with
> getLineWidth(int)
> so as to take into account each page's real height.
> This fixes the positioning of footnotes when the page bpd is not the same for
> all
On Jan 18, 2008 12:20 PM, Vincent Hennebert
<[EMAIL PROTECTED]> wrote:
> Andreas L Delmelle wrote:
>
> > I have always somehow assumed there to be a threshold in the most common
> > cases. In the sense that certain (maybe in fact even the bulk of)
> > feasible breaks can already be excluded quite
Andreas L Delmelle wrote:
Just wondering about some KnuthSequences for spaces I noticed during
a debug-session:
glue w=0 stretch=10008 shrink=0
penalty w=0 p=0
glue w=3336 stretch=-10008 shrink=0
What does it mean that the latter glue can be stretched by a negative
amount?
Why not:
glue w=3
(I see that Jeremias agrees with Andreas about how to interpret the nested
keeps, so I reply just once)
Andreas L. Delmelle wrote:
In very rough terms, the logic behind it would be:
if a given break #1 has a plain adjustment ratio of 3 and a governing
keep of "auto",
and the next break #2, re
Andreas L. Delmelle wrote:
That's one detail I was still unsure about. Only if the other factors
remain identical, the algorithm would prefer a break at penalty 50
over one at penalty 100... but if the value of the penalty is only of
marginal influence as you suggest, then this would indeed no
Firstly, hi all! It has been quite a long time since I last posted or
committed anything, but I'm still here!. :-)
Then, congratulations for all the great progresses fop is making!
And finally, concerning the keeps ...
Andreas L. Delmelle wrote:
[inserting penalties with higher value to repr
Vincent Hennebert wrote:
Hi Luca,
Hi!
I had a look at your patch and have several comments:
- I see you re-enabled the noBreakBetween method; I don't think it's
a good solution because it artificially prevents some nodes to be
created, which even if bad may be necessary for some complex
On Mon, 26 Mar 2007, Luca Furini wrote:
I'm attaching a diff file showing the changes
Well, *now* I'm attaching bla bla :-)
Regards
LucaIndex: src/java/org/apache/fop/layoutmgr/breaking/FootnotesRecord.java
=
Hi all
I recently had the time (and the pleasure) to look at before-float
implementation branch, and I played a bit with it.
I focused on the handling of footnotes, as I noticed that sometimes they
were placed on a page following their citations without a real necessity
to do it; as I wrote
Vincent Hennebert wrote:
I have some questions regarding the handling of Position elements. I'm
not familiar with that part of the code yet, and as there is little or
no javadoc for those it's a bit difficult to guess their purposes just
by looking at the code.
What's the purpose of a LeafPositi
Vincent Hennebert wrote:
I've had a quick look, that's not handled currently. At some place in
the code the space-before set on the separator is converted into a
MinOptMax(opt, opt, opt).
If I remember correctly, the separator bpd is taken from the generated
area (so there isn't any stretch o
Vincent Hennebert wrote:
I don't think there is much you can do in that case. It appears that the
15 lines of text at 12 pt exactly fill the 3 inch-high page. So that
makes a feasible node which is always preferred to too-short nodes.
Change the page-height to 3.1 inch and you no longer have the
Hi all!
At long last, I'm finally allowed some time to look at the float branch
and ... wow! Really impressive, a great lot of good work!
In order to apologize for my long absence :-) , I'm trying to see what's
wrong with the failing testcases, in particular the ones with footnotes.
Looking
I've just updated my local copy of trunk and rebuilt.
At first, I could not be able to successfully complete the compilation, as
I received an error concerning the file
src/java/org/apache/fop/text/linebreak/LineBreakUtils.java non containing
the class org.apache.fop.text.linebreak.LineBreakUt
Hi all
I have a patch fixing bugs 41019 and 41121, for both trunk and float
branch, and I'm wondering how it's best for me to proceed in order to
avoid merging problems: should I change both trunk and branch, or just one
of them?
The patch is extremely simple and does not break any testcase:
Manuel Mall wrote:
After making the appropriate adjustment to the checks in that testcase
ALL testcases are now passing!
Wonderful!
I'm really looking forward to see this great new feature!
Just a couple of doubts concerning the differences with respect to the old
implementation (I must con
Vincent Hennebert wrote:
I'd have to think more about it, but:
- perhaps the compareNodes method should compare the line/page numbers
for each node rather than the index in the Knuth sequence. Or some
mixing of the two.
The index can tell us which node allows to lay out more content, the l
Vincent wrote:
The LineLM tries, in the first instance, to avoid using hyphenation
points, so the penalty is not taken into account. But this has the side
effect of using the first glue element as a feasible break (if the
penalty were a feasible break too, it would surely be a better one, such
a
Simon Pepping wrote:
Would this be a good moment to make these features of the breaking
algorithm user configurable, like they are in TeX? This allows people
to play with the various possibilities without having to modify the
code.
I agree with you that it would be good to have them configurab
Chuck Bearden wrote:
If in a left-aligned block some typical text words are followed by a string
longer than the line-length and containing no spaces (e.g. a long URL), then the
foregoing text will have premature line breaks, i.e. halfway to two-thirds the
way into the line.
I had a look at th
Jeremias Maerki wrote:
If anyone has any requirements for XSL-FO 2.0 which I should bring up at
the workshop in Heidelberg next week, please let me know. Deadline
2006-10-16 so I have time to prepare.
Luca, are you going, too? How do you travel?
Yes, I'm going.
I think I'll travel by train,
Jeremias Maerki wrote:
I forgot to forward something to you. Bertrand made me aware of this:
http://www.w3.org/Style/XSL/2006-Workshop/
I've applied for a slot today. I hope I can get in and can make the time
to actually go there.
Today I've applied too, I hope it is not too late ...
Should
Vincent Hennebert wrote:
there is something I don't get with the handling of footnotes. When
there is not enough room on the current page to place all the footnotes,
the algorithm tries to find a place where to split them. But there is a
condition: it must be possible to defer old footnotes
(Pag
I've had another look at this.
A few debug outputs shows that the "error" arises when trying to remove
the node dem:11527.971465493918> while the list of active nodes contains
[
,
,
]
This removal, however, happens at the end of the algorithm, when the best
layout is chosen (just like Vinc
Jeremias Maerki wrote:
One of my clients reported to me that he gets a "Should be first" error
message on the log. This happens in (Page)BreakingAlgorithm.removeNode().
I get the impression that the code there is not finished rather than
that is a real error condition. I'll try to extend removeN
Jeremias Maerki wrote:
> On 19.06.2006 15:45:36 Luca Furini wrote:
> It seems to me that the prescribed behaviour requires a keep constraint
> with force = "always" to be satisfied *always* :-), even if this would
> mean having some overflowing content.
Obviously, we
Manuel Mall wrote:
What is still unclear to me is if it is worthwhile to implement this
two pass approach, i.e. use INFINITE penalties first and relax later, or if
it is good enough for 99.99% of cases just to start with INFINITE-1
penalties for mandatory keeps?
I think the second pass is nece
Manuel Mall wrote:
Yes, there is a force parameter and it seems to be always set to true
for page breaking (and false for line breaking). But it doesn't seem to
guarantee that breaks will be found otherwise we shouldn't get
the "giving up after 50 retries" message.
The "force" parameter requ
Jeremias Maerki wrote:
did you already investigate how footnotes are implemented? Can you say
anything about how similar the problem of footnotes is to before-floats?
Just so you don't have to start from scratch while there may be
something to build upon. After all, the footnotes also contain so
I've started looking at the patch attached at bug #37579, for the moment
concentrating on footnotes inside lists.
Concerning shortcoming 2) (from the bug comment):
2) Footnotes from list-item-body starts at the same position (from the
starting edge) than the list-item-body itself and not at th
Jeremias Maerki wrote:
No idea if anyone else has time to look into it. I don't think it's an
easy fix, or at least easy to isolate, because footnote handling is not
trivial. Having a good test case is instrumental in finding the problem
quickly. Usually, this is step is 60% to fixing a bug.
Simon Pepping wrote:
[...]
See http://www.leverkruid.nl/GKPLinebreaking/index.html.
Please, let me know what you think of it.
I'm going to read it carefully, it seems very interesting!
Regards
Luca
Jeremias Maerki wrote:
> The recommendation states that "The algorithm for resolving the adjusted
> values between word spacing and letter spacing is User Agent dependent."
> (7.17.2 in the candidate recommendation), so I think this is not a wrong
> behaviour: it just assumes that word spaces
Jeremias Maerki wrote:
Still trying to fix my problem with letter-spacing and fixed width
spaces. Do I understand that correctly that XSL-FO's view of
letter-spacing is different than, say, PDF's? PDF's character spacing
(PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!)
chara
Jeremias Maerki wrote:
I'm considering removing the "character" area tree object and instead
map an fo:character to a normal text area with one word child.
[...]
Does anybody see a problem with removing the character area tree object?
No problem, it's a good idea; it could help sharing a lot
(moved from fop-users as we are going into the implementation details)
Manuel Mall wrote:
the shorthand property white-space="pre" should be used or its expanded
equivalents:
linefeed-treatment="preserve"
white-space-collapse="false"
white-space-treatment="preserve"
wrap-option="no
Manuel Mall wrote:
1. The suppress-at-line-break property can be applied to all characters.
I would take the position at the moment that explicit specification of
the suppress-at-line-break property is not supported and we worry about
it at a later stage. I would certainly argue against just
Manuel Mall wrote:
This solves the first supposed problem (interaction between nbsp and
pretty-printing spaces), but the second one is still open: what
happens if we have
someContentotherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then
both spaces should be disc
Jeremias Maerki wrote:
A problem surfacing with the first expectation is the "page x of y"
problem: The usual empty block with an "EOF"-ID at the end of all
content in the fo:flow ends up on the next-to-last page which causes the
last page to display "page n of n-1". Either the breaker has to
Manuel Mall wrote:
IMO nbsp (and any other Unicode special spaces) are outside the scope of
XSL-FO whitespace handling. XSL-FO refers to whitespace as defined in
XML. In XML only x#20, x#9, x#a, and x#d are considered whitespace.
Therefore nbsp does not need to be considered when looking at
w
Manuel Mall wrote:
The problem is the coding model used for Knuth element element generation for
spaces is flawed. What is done is that the only difference between normal space
and NBSP is an infinite penalty at the beginning of the sequence. However, some
sequences are pretty long and involve
Manuel Mall wrote:
What about using the UnresolvedElements? Just as per the block-level
space resolution, each inlineLM could append at the beginning and at
the end of its element list an UnresolvedElement storing its border,
padding and spacing information.
I don't know anything about the Unr
Manuel Mall wrote:
As far as I remember our last discussion was about who should generate the
Knuth element lists: The individual layout managers or the Line layout
manager. You argued in favour of retaining the current system and I tended
to favour the moving it up the hierarchy to the line LM.
Manuel Mall wrote:
[cut]
Hi Manuel!
I was just wondering how we could proceed with the breaking / white space
handling stuff we started discussing some time ago (if you have time and
will to do it, obviously).
Regards
Luca
Hi all!
I apologize for having been not very active for the last weeks, but at
long last things should change: next week I will be in San Jose
(California) attending a conference about digital publishing, and after
that I should have some time to spend working on FOP (and I really can't
wait
Manuel Mall wrote:
Luca,
why does our line breaking algorithm insist on having at least one Box
in a paragraph? Is that inherent in the Knuth algorithm, i.e. can't it
deal with empty paragraphs, that is paragraphs containing only Glue/Pen
elements?
If I remember correctly, a sequence starti
Manuel Mall wrote:
c) Your initial thought is that the Line LM should then provide enough
information to the LMs to generate their Knuth sequences while my
initial thought is that the Line LM generates the Knuth sequences and
provides enough information for the LMs to generate their areas.
I
Relaxed validation for border and padding on region-*.
I see that, at the moment, with relaxed validation FOP does no more stops
with an error if a region has borders / padding, but anyway the borders
and padding are not painted (and even taken into account).
I was wondering whether this i
Starting from your final summary:
Manuel Mall wrote:
IMO FOP should limit itself to:
a) Use kerning only for consecutive characters within the same fo
Ok, but more on this later in this message ...
b) Limit itself to the kerning information in the font
Ok
c) Only apply kerning if the let
Jeremias Maerki wrote:
You will have seen that I've been working on overconstrained documents.
5.3.4 Overconstrained Geometry is more or less implemented, so now I
need to have a look at 4.3.2 which proves quite difficult to understand.
At least I can't make much sense of it ATM.
[...]
If anyo
Manuel Mall wrote:
I wonder if the same argument does apply to kerning as well? The moment
you change font-size, text-decoration, background-color, alignment and
the like, which is what fo:inline is mainly for, you create a barrier
with respect kerning. Or to put it differently, I believe kern
First of all, thanks for your comments: I really tend to forget in a short
time all the details concerning white space!
Manuel Mall wrote:
Glyphs are only allowed to be merged if they carry the same / matching
set of property values. Personally I would not be concerned if we
therefore limit t
Manuel Mall wrote:
After that we really need to redesign the line breaking stuff. Not the
Knuth approach (and the implemented algorithms related to that) but the
way we arrive at the Knuth sequences and iterate and process the text
elements. This needs to be done to be able to do white-space-t
Jeremias Maerki wrote:
The first concerns indent inheritance [...]
So what I'd like to do is implement the alternative behaviour as a
configurable option in the FO tree. The default would still be what the
specification describes (see [1]), but users would be able to set a
switch that would
I wrote:
Implementation of hyphenation-ladder-count.
Just a couple of annotations:
- this implementation does not store any extra information inside the
nodes: the algorithm checks wheter a break is ok or not using a for loop;
if you prefer, I could change this so that the number of consecu
While working on the implementation of hyphenation-ladder-count, I noticed
that at the moment the property system can return "illegal" values
coming from the fo file instead of the "fallback" value defined by the
specs.
There are significant differences in wording between XSL 1.0 and 1.1: for
Manuel Mall wrote:
Not sure what other committers and the PMC think but as a vote on the
release has started I would suggest no further changes to the codebase
unless agreed?
What I am saying is - by all means do the development but don't put it
back into svn until after the release.
Ok, t
Manuel Mall wrote:
Hmm, just changed the value to 3000 (I think that's the value suggested
in the article) and there is no change in hyphenation behaviour with the
above mentioned example. That makes me a bit suspicious...
I traced the beheviour of the breaking algorithm applied to the first
Manuel Mall wrote:
In preparation for the upcoming 0.90 release I was reviewing the
examples in examples/fo/basic. When looking at the output of hyphen.fo I
noticed that in both the English hyphenation example and the German
hyphenation example 4 consecutive lines ending with hyphens were
gen
Manuel Mall wrote:
What I observed is that most of these issue cannot be solved by looking
at a single character at a time. They need context, very often only one
character, sometimes more (e.g. sequence of white space). More
importantly the context needed is not limited to the fo they occur i
Manuel Mall wrote:
Here are some of the combinations I have identified:
1. Non breaking / non elastic space => probably just a normal character,
i.e. part of a word.
2. Non breaking / elastic space - eg. U+00A0 Non breaking space
=> Must prevent break
=> Must handle text-alig
Manuel Mall wrote:
Luca wrote a longer response to this but my mail reader doesn't like the
character set (is that topical or what?).
Sorry, it looks really horrible ... still don't know what went wrong, but
I won't do it again! :-)
Any way at end Luca ask the question about the UAX#14 line
Manuel Mall wrote:
So we end up with only two cases to consider: preserve white space and
remove white space around a line break created by the Knuth algorithm.
1. Preserve white space: IMO in this case the space itself is actually
not a break opportunity but there are now two break opportuni
Manuel Mall wrote:
Side note: FOP doesn't quite do the same internally, i.e. a character
explicitly specified using is handled separately from
'plain text'. If someone would write a style sheet which does a
transform of every character into a object and would
feed the output to FOP the form
Manuel Mall wrote:
> But we need to know which spaces can be adjusted, and which cannot.
> If we don't wont to duplicate the logic for the "space recognition",
> the SpaceAreas must simply have a boolean value stating whether the
> space is adjustable, so that the renderers won't need to look at
Manuel Mall wrote:
> I added a boolean attribute in SpaceArea that is true for adjustable
> spaces (at the moment it is not used, but I will fix it soon).
Why would you envisage this is required by the renderers?
I can only speak of the PDFRenderer, as I don't know the other formats
very we
I wrote:
Manuel Mall wrote:
> There is no need to expose creation of the Space/Word areas directly
> to TextLayoutManager either. TextArea could easily expose an addWord
> and an addSpace method instead of the monolithic setText. In the end
> it probably boils down to me arguing that the set
Manuel Mall wrote:
There is no need to expose creation of the Space/Word areas directly to
TextLayoutManager either. TextArea could easily expose an addWord and an
addSpace method instead of the monolithic setText. In the end it
probably boils down to me arguing that the setText logic currentl
Manuel Mall wrote:
I have a question on this. You break in TextArea the text into words
based on CharUtilities.isAnySpace. Is this guaranteed to be consistent
with the breaking and adjustment calculations in TextLayoutManager? I am
concerned we may be using different rules for word breaking in
Manuel Mall wrote:
While investigating if we could use the standard java.text.BreakIterator
to determine line break points I noticed that FOP uses in addition to
space, zero width space, hyphen also the forward slash as a valid line
breaking character. The Java BreakIterator does not recognize
Jeremias Maerki wrote:
I'd prefer to make the area tree more detailed and the renderers
simpler.
Maybe we could use a trick to minimize the memory increase by creating
an additional "word" area as a child to the text area so we don't have
to replicate the traits for each word. WDYT?
So, yo
l one! :-)
--- Additional Comment #8 From Luca Furini 2005-10-18 12:53
Quotation from the pdf reference, version 1.6, section 5.2.2 Word spacing:
"Word spacing is applied to every occurrence of the single-byte character code
32 in a string when using a simple font or a composite
Fixing a ClassCastException due to the incorrect "pattern" of elements
representing a space checked when there are inline borders and padding.
The testcase inline_border_padding_block_nested_2.xml stil does not pass:
there is a failing check concerning ipda. But at least there are no more
exce
Jeremias Maerki wrote:
I think it's not that simple in the Knuth approach because you cannot
just switch off the breaking as a paragraph is always broken as a whole
("total fit" in Knuth's terms). The easiest would be to simply generate
a zero-width box for the no-wrap inline followed by a har
Manuel Mall wrote:
Is that actually conceptually the right thing to do, that is removing
the trailing spaces before the end of a block as part of the Knuth
handling?
For leading spaces it is done somewhere completely different (and
currently in the same piece of code it is done incorrectly f
Manuel Mall wrote:
"inline_border_padding_block_nested.xml". If you run the test case as is
you get a "Expect inline sequence as first sequence when last paragraph
is not null" message.
The first message refers to the first block in the testcase: I think this
has something to do with the cor
Manuel Mall
I would appreciate if you could please have a look at test case
"inline_border_padding_block_nested.xml". If you run the test case as
is you get a "Expect inline sequence as first sequence when last
paragraph is not null" message. If you comment everything out and
uncomment the la
Fixing a bug reported by Jeremias affecting the handling of glue and
penalty elements after a break when the algorithm restarts.
Now it should be ok. A nasty little bug, anyway ...
Unfortunately, I had to duplicate a few lines (a for loop looking for glue
elements after a feasible break): the
Luca Furini wrote:
I'm going to see what happens ...
I've found the bug!
The width, stretch and shrink of the suppressed elements after a break is
taken into account in BreakingAlgorithm.addBreaks(), but this method is
called only if everythings goes well; in your test there is
Jeremias Maerki wrote:
I think I've just stumbled over a problem in the Knuth algorithm.
I'm going to see what happens ...
Regards
Luca
Peter B. West wrote:
There seem to be some misapprehensions about what you are attempting;
perhaps they are mine, so please clarify this. As I understand it, the
mature, well-documented technology is the line-breaking, as in "Breaking
Lines Into Paragraphs." Using this model for page-breakin
Peter B. West wrote:
Thanks to Luca for his (perhaps entirely co-incidental) posting to the
Wiki.
Well, not entirely co-incidental! :-)
I started writing the page some time ago, but never found the time to
finish it: your message made me think I really couldn't put this off any
longer, so I
Jeremias Maerki wrote:
What is the expected output?
In this case it has to generate a blank page IMO.
Oh, right, I did not think of an empty page! :-)
The problem is with the "page x of y" hack that won't work like this if
the last empty block ends up on the second-to-last page. [...]
Wha
1 - 100 of 180 matches
Mail list logo
