LayoutStrategy
entirely. That would solve Jeremias's problem that started this thread.
...
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
J.Pietschmann wrote:
I've got a lot of ideas myself, perhaps too many. What the
project needs is *working* *code*.
Working code is predicated on working ideas, is it not? That's why I
asked about
J.Pietschmann wrote:
Peter B. West wrote:
(does Jrg work?),
Not in the archive.
I know you are a long-time advocate of sticking with the codebase, and
have been very critical of my approach, so I don't want to draw any
unwarranted conclusions here. Does the above mean that you are
interested
in HEAD.
http://java.sun.com/features/2003/05/bloch_qa.html
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
Peter B. West wrote:
Herewith some notes on the tortured relationship between the two. As I
don't know much about layout in HEAD, I am hoping that differences and
(hopefully) correspondences between my ideas and the HEAD redesign can
be pointed out by wiser HEADs than mine
,
Shouldn't this one go into fop/fo/properties?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Finn Bock wrote:
[me]
Now that ant.jar has been removed, the project is slightly less
friendly to eclipse since ant.jar is required by the files in
org.apache.fop.tools.anttasks.
It is easily solved locally, I just wanted to point it out.
[Peter B. West]
Finn,
I've been trying to find
Victor,
The statements are getting extreme. Let's just agree to differ. I'm
happy to let my code and the design that underlies it do my talking.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
at the nasty cases as I
do, but comments are, as always welcome. Victor will be upset, I know,
but I can't see the separation of FO tree building and Area tree
building. Keiron may be screaming, That's what I was doing, in which
case my apologies.
Peter
--
Peter B. West http://www.powerup.com.au
this one. How
did you do it?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already
Victor Mote wrote:
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions
%2Fplainrev=1.1.2.1
There may be some sets I haven't covered, but that should give you a
feel for it. Any questions?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
when ANT_HOME is defined and valid, and gives the
instructions when it's not defined. Do you need more extensive test run?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand
methods
in Property.Maker.
A compiled version of my changes can be downloaded here:
http://bckfnn-modules.sf.net/fop.jar
I'm pleased to see that ideas from alt.design are making their way into
the HEAD redesign. I will assist where I can.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest
able to demonstrate it, that the alt.design approach gives
greater flexibility in assigning intermediate and undetermined values to
properties.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
classes and check the java files into CVS.
+1
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Jeremias Maerki wrote:
I can do that but someone will have to test the unix script for me.
On 11.12.2003 10:33:34 Peter B. West wrote:
Removing ant, fair enough, but why the build scripts? Shouldn't they be
extended a little to check for the presence of an ant installation and
make
to org.apache.fop.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
looking at extending it to cope with footnotes in tables within columns.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
Peter B. West wrote:
...
The topic at hand is what API is needed for the FO Tree to be able to pass
property values to its clients.
Ok. The trouble is that the relationship between FO Tree and Area Tree
is, for me, still very much an unresolved question. When we start
worlds. See fop.fo.FONode.java in the alt.design tree; notably
makeSparsePropsSet()
BitSet specifiedProps
PropertyValue[] propertySet
PropertyValue[] sparsePropsSet
final int[] sparsePropsMap
final int[] sparseIndices
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
by procedures like
interning strings. Note, though, that the process of resolving
properties does eliminate most strings. My objective was that when
areas were being laid out, the relevant properties would all be directly
available.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest
Victor Mote wrote:
Peter B. West wrote:
...
Yes, this is the real issue. Since an fo:marker's content can be used more
than one place, this requires that its contents be grafted into the tree
where needed.
I think the only trick here is to pass the static content context back to
the get method so
Victor Mote wrote:
Peter B. West wrote:
2% of what? Of a reference area. Of what actually gets laid out on a
page. If a single flow object gets laid out over more than one page,
that reference may vary, but nothing changes in the FO Tree. It makes o
sense to second-guess the Area tree within
/traits.html for a summary of
traits. I can't recall whether it is complete, but I scoured the Rec
for references, and put what I could find in there.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
, but I am thinking of something along the lines of a
co-routine, implemented by message-passing queues, similar to the
existing structure of the parser/FOtree-builder interaction.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
J.Pietschmann wrote:
Peter B. West wrote:
Although not mandated in XSL-FO, CSS2 offers a number of methods of
font matching, only some of which preserve metrics. The FO User Agent
is free to make implementation-specific decisions about this, I
assume. My main interest here is in whether we
J.Pietschmann wrote:
Peter B. West wrote:
This is why I was talking some time ago about a PropertyValue type which
is an RPN-style expression, which can be rapidly resolved without
recourse to the general parser.
I'm not quite sure what the intend of this sentence is.
The maintenance branch
subtrees in a timely manner, and 2) serialize subtrees for
efficient caching and retrieval when they will be needed at some time in
the future.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
Peter B. West wrote:
What about font-size=12pt+2%+0.8*from-parent(height div 32) ?
Good question. Make it
font-size=12pt+2%+0.8*(from-parent(height) div 32) though. Even
nastier is
font-size=12pt+2%+0.8*(from-nearest-specified(height) div 32)
because in markers and in static
, Baskerville)
that does not exist on the first system, but does on the second, what
result should be expected?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
of areas in the Area Tree.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
The set of property values relevant to a
particular FO are
available in a sparse array, accessible by the int
index corresponding
to the Property.
Which source file has the enumerations of the
properties--I'd like to see how you
fo.FOPropertySets.java
fo.FObjectSets.java
You will probably also want to look at
fo.PropNames.java
and
fo.FObjectNames.java
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
J.Pietschmann wrote:
Peter B. West wrote:
If a user renders a given .fo file on two different systems, using the
same renderer (say, PDF), and specifies a font family (say,
Baskerville) that does not exist on the first system, but does on the
second, what result should be expected
memories?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
And now for a little digression on code generation.
My own view of code
generation by XSLT transformation can be summed up
as:
Why, Peter, you're in disagreement with everyone else
on this issue! (So what else is new? ;)
Everyone
of the font file.
p
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
+1
Victor Mote
+1
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
John Austin wrote:
On Tue, 2003-11-18 at 22:36, Peter B. West wrote:
...
Overnight I ran another test, using xml-fop_20031118231549.tar.gz
and the final summary of the call tree SUGGESTS that things are
better (although the results may be incorrect).
...
My focus is on performance. I came
a
recommendation. One of the reasons for the FO Tree isolation work was to
make issues like this easier to address -- except for the FO Tree API issues
(which should be resolved first), you don't have to worry at all about
breaking layout or renderers.
Peter
--
Peter B. West http://www.powerup.com.au
Victor Mote wrote:
Peter B. West wrote:
The last assessment of the situation that I can recall on this list was
that property handling is working satisfactorily so there is no need to
pay any attention to it. Yes, really.
I don't think this is quite right. It is a matter of priorities
of
mutual respect. That said, we *are* still trying to sort out some design
Ah yes! The old vigorous and spirited exchange of views.
AKA a full and frank exchange of views.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
. I posted an epitaph to my stacks at this point.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
No shortages here.
Peter
John Austin wrote:
On Wed, 2003-11-19 at 19:50, Peter B. West wrote:
John Austin wrote:
...
My apologies to everyone on the list for the testy tone ...
You mean I might have help p*ss*ng people off ?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
a quick look at this. I'll try to have a look at it myself
tomorrow.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Only some are broken. I'll check them all tomorrow.
Peter
Peter B. West wrote:
I don't know when it happened, but the alt.design iframes for display of
code fragments are broken. They require html files containing the
html-formatted code, and these seem to have been left behind somewhere
Profiler at http://www.khelekore.org/jmp/performance.html
I suspect there are still major memory leaks in FOP and this
is one tool that will help you track them down.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
with no objectors.
The discussion thread can be followed at
http://marc.theaimsgroup.com/?l=fop-devm=106889839919803w=4
If any further information or formalities are required, please let me
and the fop-dev list know.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
Then there is no need for us to actually construct
development
snapshots. The build process is not onerous, and it
doesn't take 12
hours to build.
I agree--and am concerned that the primary motivation
for these snapshots is Clay
-reproducible bug
being reporting by a HEAD user.
There are a few issues with sticky date specifiers, which we will have
to work out and document for users. Basically, we need a formula for
getting from one -D checkout to another with the minimum of anguish.
Peter
--
Peter B. West http
finalised means depends on the complexity of the layout
strategies employed, but at a minimum, it must be maintained until the
last page containing text from the block, and the subsequent page (if
any) have been laid out, to allow for backtracking during last-page
processing.
Peter
--
Peter B
even if the block itself
doesn't span multiple pages?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
otherwise.
Well, the spec always has this phrase one or more areas.
It doesn't really explicitely deal with how multiple areas
come into existence and whether it is one area per page,
although there are the constraints on the area tree which
indicate it has to be this way.
J.Pietschmann
--
Peter B. West
Glen Mazza wrote:
Thank you both for the clarifications.
--- Peter B. West [EMAIL PROTECTED] wrote:
The area tree
describes laid-out areas to be rendered on some
medium, and
as
every area
which describes a mark on a page must have a region
in its ancestry, we
are obliged to consider
the position.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Mail troubles. Just testing.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
obviously not as much as when I was
unemployed.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
situation remains as is (and it would need a _lot_
of -1s to overcome the current vote), we can then formally request the
incubator take on XMLBeans on behalf of the XML project.
Let me know if there are any problems with this approach.
Cheers,
Berin
--
Peter B. West http://www.powerup.com.au
Victor Mote wrote:
Peter B. West wrote:
Anyone who would like to make a start on the integration of alt.design
can do two very great services.
Since my main FOP purpose in life right now is to reduce (if possible) our
lines of development from 3 to 1, this is of interest to me. However, I want
?
This is usually a good idea but may cause quite a bit of work.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
the same simplicity as, e.g., tab width or format of
names. If we follow them slavishly, we lose perspective on the code. I
don't think things like method length should even be warnings; rather
info flags, to indicate that something needs to be looked at.
Peter
--
Peter B. West http
Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
Victor,
I noticed we had to break up a function to satisfy
Checkstyle's max method length size of 150 (
http://marc.theaimsgroup.com/?l=fop-cvsm=105806596213734w=2).
That seems too constricted for our use--it's may
force parameter
my last update, I have the problem back again. It seems
like a coding problem, but the file compiles under Ant, outside Eclipse.
Any ideas?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe
, would it not be better to name them
consistently, and include a text file detailing the current versions?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED
/stevenn/
stevenn at outerthought.orgstevenn at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
done, e.g., using MessageHandler.
Bringing apps up to date will greatly ease the integration process, and
can be done, I think, without majoe trauma.
The tag for alt.design is FOP_0-20-0_Alt-Design.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
something wrong?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Victor Mote wrote:
Peter B. West wrote:
(I wouldn't say it was heated.) I am curious about the impact of
someone working without any formal IDE, and just using (X)Emacs and JDEE
for development. As far as I know, XEmacs does not support Unicode, but
if the non-ASCII characters were restricted
Font gurus,
In what circumstances are t1font-file.xsl and ttffontfile.xsl used?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email
J.Pietschmann wrote:
Victor Mote wrote:
BTW, I notice the absence of you and Peter from
http://cvs.apache.org/~sgala/nightmap.html
Ok, so how do we drive this thing? Is it zoomable? I couldn't find
pietsch on there either.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
generate invalid code - so basically they could be removed.
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
J.Pietschmann wrote:
Peter B. West wrote:
I couldn't find pietsch on there either.
Obscured by bdelacretaz, jeremias and other, even more famous
community members :-) You have to look at the source.
You wont have this problem donw under, I guess. :-)
No, it's pretty sparse, but I won't have
J.Pietschmann wrote:
Self follow-up: Is
http://www.thinkgeek.com/computing/input/keyboards/5c3f/
of some use? The text claims it reduces CVS! :-)
That's a Subversive remark!
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
about missing
CVS directories in build/ and subdirectories too on commit, which
means it somehow descends there. According to the cvs info page this
shouldn't happen either.
Am I doing something wrong?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
I have just noticed that there is no licence in build.xml, build.bat or
build.sh. I assume this is an oversight, or do we have a dispensation?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e
approach.
Glen Mazza wrote:
[Happy Independence Day, fellow Americans!]
--- Peter B. West [EMAIL PROTECTED] wrote:
The basic build principles that I will implement
include:
* No code generation or modification for normal
builds.
* All generated code and data maintained in CVS.
I don't think you
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
parties can look at the results in alt.design.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Fopsters,
I can't see a way to coonvince the Text Editor or Default Editor to
use spaces instead of tabs when editing build.xml, for example. I
resort in the end to emacs. Has anyone else worked around this problem?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
The problem is that there are different editors. The Java editor is OK,
but when you start editing xml files, for example, you get a different
editor - the Text Editor, I think. And that beast seems immune to
instruction about tabs.
Peter
J.Pietschmann wrote:
Peter B. West wrote:
I can't
further
code changes.
The MathML and Plan samples actually depend on this.
Hmmm.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL
to be
given a high profile in Apache projects. As always, resourcing is the
problem.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
That the semantics of the extensions have to be
realized somewhere is
tautological, even if those semantics are filter
out.
Tautological? Very good, Peter, you got me--it's
rare when someone makes me need to look up a word
or extensions to existing projects that the PMC or Board
considers necessary for the health of Apache.
Peter
J.Pietschmann wrote:
Peter B. West wrote:
FWIW, I think this and your earlier suggestion along these lines are
excellent ideas. Ease of installation and configuration need to be
given
Jeremias Maerki wrote:
No, of course not.
Well, ..er, ..um, no, of course. Supplementary question: was that entry
perhaps intended to be to be an exclude?
Peter
On 27.06.2003 06:36:17 Peter B. West wrote:
I just noticed
include name=lib/jimi*/
in the dist.bin.lib fileset of build.xml
. Of course, a property
for that would be nice, but at
least then you can have both.
How about that?
Very sensible. I had in mind my preferred method of dynamic balancing,
but even with that model, it is simple enough to undo the balancing on
the last page of a sequence.
Peter
--
Peter B. West
Mote wrote:
Peter B. West wrote:
pbwest 2003/06/25 10:01:01
Removed: .checkstyle1.3.0-head
Log:
Name changed to checkstyle3.1.1-head
Thanks for all of your efforts here. Is this file reliable, or is it a work
in progress?
--
Peter B. West http://www.powerup.com.au/~pbwest
Devs,
I just noticed
include name=lib/jimi*/
in the dist.bin.lib fileset of build.xml in HEAD. Is that supposed to be
there?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL
the question of whether, on the last page of a
page-sequence, the columns should be balanced. My intuitive approach
would be to balance always. However, there seems to be another
attribute required for column spill behaviour, especially for the last
page of a page-sequence.
Peter
--
Peter B. West
Peter B. West wrote:
Arnd Beißner wrote:
...
Scenarios: (always column-count=3)
Scenario 1 (just blocks with span=all):
ABC
ABC
ABC
ok, no problems.
Scenario 2 (block with span=all, then blocks with span=1)
AAA
BCD
BCD
clear so far.
Scenario 3 (blocks with span=1, THEN 1 block with span=all
presuming the result of this discussion, it wouldn't be the end
of the world if it were true. It just means that certain views of the
process are precluded.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
201 - 300 of 715 matches
Mail list logo