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
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 you
[
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-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
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
[
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
[
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 NullPointerException
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
(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, its
position can
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
and
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
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 :-)
Ok, so I think this definitely means
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
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
(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,
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
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
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
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
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
===
--- src
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
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
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.
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
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
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
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
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
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,
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
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
I've had another look at this.
A few debug outputs shows that the error arises when trying to remove
the node KnuthNode at 734 4527603+682968-135942 line:10 prev:687
dem:11527.971465493918 while the list of active nodes contains
[
KnuthNode at 734 4527603+682968-135942 line:10 prev:683
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 disagree here. I read it so
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
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
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.
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
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:
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 (!)
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 have
(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-wrap
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:
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
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
someContentnbspspaceotherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then
both spaces
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
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
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
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
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
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
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
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,
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:
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:
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
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
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 the
Manuel Mall wrote:
Side note: FOP doesn't quite do the same internally, i.e. a character
explicitly specified using fo:character.../ is handled separately from
'plain text'. If someone would write a style sheet which does a
transform of every character into a fo:character / object and would
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
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
! :-)
--- 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 font
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
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
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
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 last
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
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
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
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-breaking
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. [...]
What
Jeremias Maerki wrote:
It's an interesting idea. However, I suspect this will probably not be
necessary. We should be able to make the breaker clever enough to handle
this particular case.
When the page bpd depends on the page-masters, things becomes very
strange. Not only it's difficult to
Andreas L Delmelle wrote:
Currently, I have solved this locally by creating the pageVP with the
indefinite dimension set to Integer.MAX_VALUE.
The only things I'm still looking for are ways to:
a) retrieve the accumulated content-height/-width (or: the difference
between the initial
Andreas L Delmelle wrote:
BTW: Is it a correct assessment that implementing this should turn out
to be far simpler than fixed page-sizes? IIC, theoretically, the whole
page-breaking algorithm can be ignored for indefinite page-heights.
getAvailableBPD() would always return, say,
Hi all.
I'm noticing a strange problem: fop builds correctly, but then it seems it
is not working at all.
I'm using it from the command line under win xp, and even if I don't get
any run time exception no output file is created. Launching fop with no
parameters, or with wrong parameters
Jeremias Maerki wrote:
wrap-option is one of those few properties which work in 0.20.5 but are
not yet available in FOP Trunk. Luca, what do you think how difficult it
would be to implement it at least for, let's say, fo:block? I imagine it
would suffice to trick the breaker into not choosing
Manuel Mall wrote:
if we have a baseline-shift, eg.
some Xfo:inline font-size=smaller
baseline-shift=super2/fo:inline ...
how is that intended to be modelled with respect to the lead,height, and
middle values to be stored in the created KnuthInlineBoxes for the
fo:inline?
I think that
I wrote:
Correct handling of the combination of hyphenation and text-align =
center, left or right.
At the end, I found out that this was not the same problem as bug 36533,
but another bug specifically concerning the elements created to represent
hyphens.
I think that Manuel has been the
I wrote:
Factorized the creation of the elements in TextLM: now both getNextKE()
and getChangedKE() call the same methods createElementsForASpace() and
crateElementsForAWordFragment().
This should definitively solve bug 36533.
Besides removing duplicated lines and inconsistencies, I hope
Manuel Mall wrote:
yes, that is an option. What I am unsure about here is that the
children, typically text areas, do not take the line spacing into
account when reporting their bpd, that is the usually 10% space above
and below the character. So what is the correct bpd for an fo:inline
Jeremias Maerki wrote:
I'll start from scratch to come up with a better strategy of
implementing these rules. I'll probably start by documenting a few cases
in the Wiki and try to develop the right element list for them. After
that I'll try to find out who exactly to implement everything.
Manuel Mall wrote:
this is my code after integrating your patch to add the knuth elements
for line end / start border/padding for the common justify=start or
end case. What I am getting now is a space at the beginning of each
line break!:
if (lineStartBAP != 0 || lineEndBAP != 0) {
Manuel Mall wrote:
Next problem: border conditionality - how do I model that with the Knuth
approach? At the time I add the Border/Padding start/end boxes we don't
have line breaks so they really only cover the .conditionality=discard
case. How do I tell the algorithm to leave enough space at
Manuel Mall wrote:
But if we have a long fo:inline stretching multiple lines this seem to
give the wrong results from the Inline LM perspective. For example if
the fo:inline finishes in the middle of a line followed by more text the
Line LM will not set the LAST_AREA flag when calling
Manuel Mall wrote:
These two paragraphs confuse me - sorry. My understanding was:
discard = start/end borders/padding only at the start and end of the
whole fo:inline
retain = as discard plus start/end borders/padding on the start and end
of every line the fo:inline spans.
Sorry, you are
Richard W. wrote:
I'm starting now. I've had to rename inline_block_nested_\#36248.xml
to inline_block_nested_bug36248.xml to get the junit task to build.
I had to rename that file too; I have win xp.
Regards
Luca
Speaking of extensions, I'd like to resurrect the layout extensions that
were part of the code used to start the Knuth branch, but I want to be
sure I'm allowed to do it.
The set of extensions (a couple of new properties, and some new value for
an existing one) is aimed to give the user more
Jeremias Maerki wrote:
For those who don't want to run BatchDiffer themselves, I've uploaded a
ZIP full of PNGs, one per layout engine test case combined from output
from the PDF, PS and Java2D renderers.
Just an idea ... what about an option to have the output from two
renderers and the XOR
Chris Bowditch wrote:
+ * Conditional space support, i.e. space-before.conditionality=retain
Chris, doesn't this work already?
As far as I can remember the correct space resolution is still missing, so
for example the space-after of a block is not added to the space-after
of the following
Chris Bowditch wrote:
I just knocked up a small test case and although retain is honoured,
discard is ignored. I knew it wasn't quite yet working but didn't
realise retain was working :) I'll update the Wiki.
Could you please also attach your file?
I have tested a simple sequence of blocks
Chris Bowditch wrote:
Here is the sample:
Thanks!
I have tested a simple sequence of blocks with conditional spaces and
the output seems ok; the output of the testcase space-block2.xml seems
correct too (I'm going to add checks).
Not true, space-block2.xml does not work. On the second
J.Pietschmann wrote:
Maybe I'm wrong in trying to do so, but I'd like to handle both
formatting objects in the same way.
If page numbers can be resolved to strings early, it should be
done. All the hassle for space readjusting, and perhaps reflowing
content, should be reserved for forward
J.Pietschmann wrote:
In the maintenance branch, the formatted page number string was produced
just as a new page was set up. I wonder whether the page sequence LM can
put the current page number string into the layout context?
This could work for page-numbers but not for
Firstly, thank you all for your suggestions.
All your interesting replies led me to this conclusion:
- in most cases, it is enough to make some local adjustments in each line
containing page-numbers or page-number-citations;
- sometimes, when a particularly elegant output is needed, it would
There is a layout problem with fo:page-number and fo:page-number-citation,
already pointed out but still unresolved.
I think, these formatting objects are very similar, even if their actual
handling is quite different: they both must be replaced by an information
(a page number) that is (or
1 - 100 of 122 matches
Mail list logo
