DO NOT REPLY [Bug 20797] New: - Infinite Loop for block text exceeding page size

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20797

Infinite Loop for block text exceeding page size

   Summary: Infinite Loop for block text exceeding page size
   Product: Fop
   Version: 0.15
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am encountering infinite loop in FOP and was wondering if there is any 
solution for it?
 
The "remark" value is supposed to store up to 4000 characters. And I have to 
keep them together in a page if the size can fit into the available space for 
the current page. If the block size is bigger than the available space then 
supposed to allow the whole block of text to move to the next page. However, 
what we are encountering is that the entire block size could be larger than can 
be contained in a single page and we encountered infinite loop.
 
Is there anyway to circumvent the occuring of the infinite loop and yet allow 
to keep the entire block text together when it can fit into a page size and 
allow it to overflow into subsequent pages if the block text exceeds a page 
size ?
 
Please help. Any help is greatly appreciated.
 
Following is a portion of the template we using
 

 
 
 
  
   
   
   
   
   

 
  *
   
 
  
 
   
   
  
  
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20792] - Exception with a big image but ok with a small one

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20792

Exception with a big image but ok with a small one

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-16 07:53 ---
The image didn't fit on a page. See also
 http://xml.apache.org/fop/faq.html#boxoverflow

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20797] - Infinite Loop for block text exceeding page size

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20797

Infinite Loop for block text exceeding page size

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-06-16 07:57 ---
Please use the fop-user list to ask questions.
FOP currently can't break blocks larger than a page which should be kept
togehter. You can try to solve the problem at the XSLT level, by attempting
to split the block in a meaningful way.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Nomination of Glen Mazza as committer

[Jeremias Maerki]

I agree, so +1 from me.

On 16.06.2003 02:12:27 Victor Mote wrote:
> Being the greenest committer, I had hoped to defer this nomination to a more
> senior developer. However, I think it is appropriate to nominate Glen Mazza
> for committer status. He is knowledgeable and thoughtful, and I think it is
> in the interest of the project to turn him loose so that he can keep working
> without having to wait on us.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Jeremias Maerki]

That concerns me as well. Personally, I must say that my fun time is
nearing an end. I need to reestablish a more or less regular income in
the next couple of months. So a lot of my energy is focused in this
direction which means less participation in this project. But it doesn't
mean I'm going away.

On 16.06.2003 00:11:53 Glen Mazza wrote:
> No response on the below questions from any committer,
> and I'm concerned about the drop-off on the FOP-DEV
> mailing list over the past few weeks (at an
> extrapolated 170 emails on FOP-DEV for the month, this
> would be our lightest month since Dec. 1999!)  



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Nomination of Glen Mazza as committer

[Oleg Tkachenko]

Jeremias Maerki wrote:
I agree, so +1 from me.
Here is my +1.
--
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Nomination of Glen Mazza as committer

[Christian Geisert]

Oleg Tkachenko schrieb:
Jeremias Maerki wrote:

I agree, so +1 from me.


Here is my +1.
+1

Welcome Glen


Gut so, jetzt müssen wir seine Patches nicht mehr bearbeiten.

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Bertrand Delacretaz]

Le Lundi, 16 juin 2003, à 02:12 Europe/Zurich, Victor Mote a écrit :

...However, I think it is appropriate to nominate Glen Mazza
for committer status
+1, welcome!

-Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

Victor Mote wrote:
Glen Mazza wrote:


No response on the below questions from any committer,
and I'm concerned about the drop-off on the FOP-DEV
mailing list over the past few weeks (at an
extrapolated 170 emails on FOP-DEV for the month, this
would be our lightest month since Dec. 1999!)


At the moment, most of my design questions are answered, and it is merely
:-) a question of finding time to implement.

I'd like us to continue progress on both Trunk and
Alt-Design until (1) at least one of the two methods
are finished or (2) they've been merged completely.  I
would be happy to work as best I can towards both
goals.  Do the committers need to have a vote on this?


I think most of us treat Alt-Design as Peter's "baby" and expect him at some
point to propose a reintegration of some or all of his work into the trunk.

We need to get working again.


There are probably multiple opinions about how best to proceed. My personal
view is that our biggest problem is not integrating Alt-Design, but rather
integrating the maintenance branch and the trunk so that we are releasing
and developing in the same branch. To that end, I am (as we speak) trying to
untangle Driver into Session, Document, and RenderContext objects, as the
first step toward refactoring to LayoutStrategy. So I guess I am working
along a different line, but working nonetheless.
Victor,

I'm pleased and surprised to hear that most of your design questions 
have been answered.  What scope of design are you talking about?

I am a little more disturbed to hear that alt.design is once again my 
baby.  I have been posting here intermittently over the past few weeks 
with design notes that explore the implications of my discoveries about 
the impact of some particulares of the Rec on my current properties 
handling, the implications for the layout of those issues and the 
integration of alt.design, and some general questions of layout design.

In making those notes, I have been at pains to illustrate my points with 
either new diagrams or reference to existing ones.  I have gone to those 
lengths because I an anxious to communicate my ideas as accessibly as 
possible.  When I was working on the properties implementation, I found 
that my attempts to explain what I was doing were met with blank 
incomprehension.  I am trying more diligently to circumvent such a 
situation now.

However, it seems that I am still working in something of a vacuum.  I 
have had a little feedback, but it did not relate specifically to the 
possible impact of my ideas or the alt.design properties integration, on 
the design of layout.

All of this may simply be because my comments are not considered 
relevant.  Nonetheless, I believe that the *kind* of design commentary I 
am making is of great value in the development of the design of layout. 
irrespective of the particulars of my work.  One of the problems of 
getting more people involved in the redesign work is the opacity of the 
process.  It seems to me that the redesign documentation is, to too 
great an extent, simply the code.  I say this in spite of the other 
documentation that has been done.

Add to this the opacity of the code itself, evidenced by a number of 
Joerg's comments over the past few months, and I think there is good 
cause for extensive documentation and diagramming of the intention and 
direction of the design, and of various critical algorithms, using a 
combination of text, diagrams and code fragments, in a way similar to 
the approach I have been attempting with the alt.design documention and 
recent discussions.

The easiest way to proceed is to hack existing code.  It's the 
conventional wisdom, it gives instant gratification and feedback, and 
one always has something that works - sort of.  Granted, the HEAD base 
incorporated new design approaches when it was initiated, but my feeling 
is that HEAD redesign is now progressing by the above method.  So far, 
this approach to development has not succeeded in resolving the thornier 
design issues thrown up by the Rec.  I'm not saying that Kieron, Joerg 
and yourself will not succeed where others have failed.  But I would 
like to see the process made as transparent as possible.  (Your work on 
the rationalisation of the web site is a step in that direction.)

One of the major virtues of trying to explain what one is attempting to 
do in advance, is that it wonderfully clarifies the thinking.

Here endeth the gripe.  Thank you for listening.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Design notes - layout

[Peter B. West]

Fopdevs,

Triggered by Victor's comments on the Session/Document division, I have 
been thinking about layout issues in a general way, focussed on my 
feeling that the processing of the Flow Objects needs to be driven by 
the Area tree processing; i.e. that the FO processing needs to be pulled 
by the demands of area layout.  I have three diagrams illustrating the 
preliminary ideas.  Because of size constraints associated with mailers, 
I will post these in three messages.

The first, attached concerns Document level.  In terms of alt.design's 
pull parser, Document will be responsible for setting up the SAX parser 
and the FoXmlEvents buffer as separate threads.  It pulls through and 
processes the layout-master-set and declarations subtrees, creating 
Declarations and LayoutMasterSet objects.  One of the methods of the 
LayoutMasterSet is pageFactory(), however named, for providing a new 
Page object meeting particular constraints.

When these are done, the DocumentLayout process (which may or may not be 
a separate object) starts a loop comprising getPageSequence and layout 
PageSequence methods.  GetPageSequence interrogates the FoXmlEvents 
buffer for new page-sequences.

LayoutPageSequence is illustrated in the following message.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Design notes - 2. LayoutPageSequence

[Peter B. West]

The interesting thing about the layoutPageSequence process/method is the 
division of labour between the PageMaker and the PageSequence.  In this 
view, the processing of the page-sequence has a life independent of the 
layout of individual pages.

Referring back to my earlier notes on layout transactions, consider the 
situation in which the attempt to layout a line-area from some block is 
rejected because the receiving page is full.  Assume, for the purposes 
of the argument, that this occurs with a nested set of FOs.  One page 
fills, and another must be provided, while a nest of FOs has pending 
output.  This situation determines the essential logic of the processing.

The layoutPageSequence action starts a PageMaker, possibly as a thread 
of its own, and then proceeds with the page-sequence processing, pulling 
elements from the buffer as required.  These begin with the 
static-contents, which, harking back to another earlier message, are 
simply buffered for later processing and possible merging with buffered 
maker subtree events.

When these are out of the way, the action gets the flow, and starts to 
pull the content blocks of the flow.  As each top-level block is found, 
the contents of that block are recursively laid out.  More detail of 
this process in the next diagram.  Note that at this stage, nothing is 
known about the containing page.

Eventually the top-level block layout action demands page space.  This 
is where the min/max requirements will make themselves known.  Such 
demands from a top-level block within a flow are passed to the 
PageMaker.  When the first of these demands, or the first demand after a 
page has been filled, is encountered, no page exists to receive the 
block contents.  The PageMaker consults the LayoutMasterSet.pageFactory 
for a new page, and constructs the page and region viewport and 
reference-areas.  These are then available as receptacles for the 
contents of the top-level blocks.

The current and subsequent top-level blocks then negotiate space 
requirements, acting as go-between to the PageMaker and its own 
descendants.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Design notes - 3. Layout Block

[Peter B. West]

Top-level block layout is a recursive process with a number of phases. 
In the first phase, the descendants are "laid out" assuming infinite 
space, and the range of space requirements is determined.  The initial 
areas are created and inserted into the area subtree of the top-level block.

When this process completes, a demand for page space will percolate up 
from the descendants.  The final form of this space deamnd is passed to 
the PageMaker.  Note that in the unoptimised state, this will be a 
demand for a single block of IPDim sufficient for the contents of the 
descendants.

Constraints come back from the PageMaker, and the process of 
constructing layout transactions begins in earnest.  For any top-level 
block, this will usually culminate with the exhaustion of the contents 
of the block, but in other circumstances the page will fill while some 
line of descent is pending.  The subsequent demand for page space will 
be made in the absence of knowledge about the receiving page areas.  It 
will be possible to optimise on the assumption of similarity ot the 
previous page, but I am looking here at the basic logic.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Peter B. West]

+1

plus comments.  I am happy to see new committers come into the project. 
 I recall, however, that it took me a year to gain that status, a year 
during which I wrote a considerable amount of code which I maintained in 
my ISP account.  My crime was that I did not toe the Party line.  I hope 
those days are gone, and that, should a developer happen along who 
contributes to alt.design, and expresses a desire to continue to work on 
it, he or she will be granted committer status with the now customary 
alacrity.

Peter

Victor Mote wrote:
FOP Developers:

Being the greenest committer, I had hoped to defer this nomination to a more
senior developer. However, I think it is appropriate to nominate Glen Mazza
for committer status. He is knowledgeable and thoughtful, and I think it is
in the interest of the project to turn him loose so that he can keep working
without having to wait on us.
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Ascii file generation questions

[Illiano, Vincent]

> Hi fellow Fop'ers,
> 
> I've built a dynamic document generation system using FOP.  I'm currently
> using version 0.20.4.  The 2 supported output formats are PDF and ASCII
> text.  I know that the ASCII renderer was never meant to be production
> quality.  However, with some tweaking, I have been able to get out of it
> what I need.  I'm including an example text output file that was generated
> by my system using FOP.
> 
> The main problem that I have found with the text output generation is the
> line-overwriting problem.  However, I have been able to fix this for the
> most part by adding extra space before the blocks where the overwriting
> occurs.  For example:
> 
> change
>   Procedure Comment
> to
>   Procedure Comment
> 
> often fixes the overwriting problem that may occur in a particular
> paragraph of text.
> 
> Is there someone on this list who can explain to me why the overwriting
> problem occurs and if it's something that could be fixed?  I can volunteer
> to dig in and do it myself with just a little guidance.  Also, is the text
> output feature planned in the redesign?  I really hope so, because I think
> text is a valid output format.  Again, I can volunteer to work on that
> feature if it's not already in the plan.
> 
> Here is the example text file.  Thanks, -Vincent
> 
>  <> 
> 

DISCH2
DMCRES
226050-5739286
701
CardioThoracic Surgery
CardioThoracic Surgery
1997072100
20030616140208
CTSURG
P
275900
Landolfo
Kevin
P
Z9
TESTPATIENT
MARY
TEST SR
023433
TX
1
Complete Report
Complete Report

The report in the patient record was created using another software database
   system. This electronic report represents the content but not the format
   of the original. For patient care use, please refer to the chart record.

DUMC
THORACIC SURGERY SERVICE
DURHAM, NC

Name:  TESTPATIENT, Sr, RN, MARY TEST PATIENT
MRN: Z9 DOB:  08/04/1935
Referring provider: Cynthia Steinem, MD; Colvin, O Michael, MD; L J Pace,  MD
Referring Cardiologist: Victor S Behar, MD
Surgeon: Landolfo, Kevin P, MD
Procedure Date:  07/21/1997

Operative Note - Cardiac Surgery

MARY TEST PATIENT TESTPATIENT, Sr, RN is a 61 year old Hispanic female from
Hamilton, who was referred by Victor S Behar, MD from Durham, NC, L J Pace, MD
from Princeton, WV, Cynthia Steinem, MD from Raleigh, NC, Colvin, O Michael,
MD from Durham, NC.

Diagnosis - Non-Coronary
   Stenosis - aortic

Procedures
   CABG x 1
   Mitral valve replacement, Aortic valve replacement

Operative Personnel
   Surgeon:   Kevin P Landolfo, MD
   Anesthesiologist:  Bruce J Leone, MD
   Perfusionist:  Curtis L King
   Assisting MD:  Joseph M Forbess, MD
   Physician's Assistant: James T Marshall, PA-C

Clinical History
   Indication(s) for Operation - Coronary:  Failed  angioplasty, Congestive
  heart failure
   Valve Disease Etiology:  Calcific
   NYHA Class:  II - Sx with moderate exertion
   Left Ventricular Function:  Normal (EF>50%)
   Coronary Artery Disease Status:  No significant  CAD indicated
   Operative status:  Emergency - first available  room with hemodynamic
  instability

Closure Techniques
   Staples

Operative Procedure
   Patient location prior to procedure: Transferred from another facility
   Anesthetic:  No Medications Indicated
   Incision Type:   Median (Full) sternotomy
   Bypass graft(s) obtained:  Left mammary artery  - Endoscopic, Left radial
  artery - Open (incision), Homograft - Open (incision)
   Left ventricular status:
  Single scar sites - Antero-apical
  Multiple scars - Antero-apical
  LV aneurysm - Posterior, Antero-apical
  Previous repair
  Hypertrophy
  Dilation
  Ischemia
   Cannulation Sites:  Vena cava
   Chambers opened:  Aorta, Pulmonary artery, Right  atrium
   Hemodynamic difficulties pre-procedure:  Hypotension
   Number of proximal anastomoses prior to cross clamp:   2
   Number of proximal anastomoses during cross clamp:   3
   Minimum myocardial temperature:  37.10 (Degrees  C.)
   Minimum inflow temperature during cross-clamp:   38.00 (Degrees C.)
   Minimum nasopharyngeal temperature:  34.00 (Degrees  C.)
   Cardioplegia infusion:  Other
   Cardioplegia administration:  Antegrade - 1400  ml
   Topical cooling:  Slush

Aortic Occlusion Method
   Not used

VALVE MATRIX
   ValveDescription Repair   Previous valve excised
    --- ---  --
   1 Aortic Stenotic, Calcified  Native

   ValveValve inserted  Valve Left   Size (mm) Suture
    ---    
   1 Aortic St. Jude 19.0  2/0

   ValveTechnique  Serial No.Model No.
    -  - -
   1 Aortic Subannular pledgets60344649

GRAFT MATRIX
   Coronary Graft Target Artery  

RE: Ascii file generation questions

[art_w]

I do not know about the future of the TXTRenderer. But I do know a little
bit about it's past.

The overwrite problem occurs because the TXTRenderer attempts to match the
positioning/layout of the PDF/PCL Renderers. Unfortunately plain text of
course does not have precise line positioning. Essentially the TXTRenderer
attempts to fit the layout onto a fixed character matrix. Quantization
effects cause the overwrite when a subsequent line ends up at the same line
in the matrix as a previous line. I do not know that there is a perfect
solution to this problem. Perhaps extra lines could be added if an overwrite
would occur, but then the layout would be compromised (perhaps this would be
better than an overwrite). One of the original constraints when the
TXTRenderer was developed was that the text output fit within fixed page
sizes (fixed number of rows/columns). Depending on your application, this
may not be important. Perhaps a "mode" could be added to preserve text
(versus preserving layout). The only consolation I have had with regard to
the TXTRenderer is that I find its output superior to many commercial
applications' lame text output (IMHO).

Art

-Original Message-
From: Illiano, Vincent [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 16, 2003 2:28 PM
To: Illiano, Vincent
Cc: '[EMAIL PROTECTED]'
Subject: Ascii file generation questions


> Hi fellow Fop'ers,
> 
> I've built a dynamic document generation system using FOP.  I'm 
> currently using version 0.20.4.  The 2 supported output formats are 
> PDF and ASCII text.  I know that the ASCII renderer was never meant to 
> be production quality.  However, with some tweaking, I have been able 
> to get out of it what I need.  I'm including an example text output 
> file that was generated by my system using FOP.
> 
> The main problem that I have found with the text output generation is 
> the line-overwriting problem.  However, I have been able to fix this 
> for the most part by adding extra space before the blocks where the 
> overwriting occurs.  For example:
> 
> change
>   Procedure Comment
> to
>   Procedure Comment
> 
> often fixes the overwriting problem that may occur in a particular 
> paragraph of text.
> 
> Is there someone on this list who can explain to me why the 
> overwriting problem occurs and if it's something that could be fixed?  
> I can volunteer to dig in and do it myself with just a little 
> guidance.  Also, is the text output feature planned in the redesign?  
> I really hope so, because I think text is a valid output format.  
> Again, I can volunteer to work on that feature if it's not already in 
> the plan.
> 
> Here is the example text file.  Thanks, -Vincent
> 
>  <>
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[J.Pietschmann]

Peter B. West wrote:
The easiest way to proceed is to hack existing code.
Text-align="justify" is broken in HEAD. Challenge: make
it work. Right aligning works, so this should be easy...
I bet quite a few people looked at it and decided there
are less challenging but equally important (to them)
things to do.


If I could get some time, I probaly could pull it.

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[J.Pietschmann]

Victor Mote wrote:
Being the greenest committer, I had hoped to defer this nomination to a more
senior developer. However, I think it is appropriate to nominate Glen Mazza
for committer status. He is knowledgeable and thoughtful, and I think it is
in the interest of the project to turn him loose so that he can keep working
without having to wait on us.
+1

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: table-row wrap

[J.Pietschmann]

susan atmaja wrote:
I have a problem with table row when the content of table cell exceeds 
the witdth specified.
Did you take a look at
  http://xml.apache.org/fop/faq.html#cells-overflow
I want the following to be the output :
Each column's value is completely displayed (no overlapping).  When the 
end of table / page is reach, I want the next values to be wrapped to 
the next row.

For example,


This does not quite match typical solutions to your problem
statement. Text can easily be wrapped inside a table cell, but
you can't easily change the number of columns and rows.
J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Comments (was: Re: Nomination of Glen Mazza as committer)

[J.Pietschmann]

Peter B. West wrote:
 I recall, however, that it took me a year to gain that status, a year 
during which I wrote a considerable amount of code which I maintained in 
my ISP account.  My crime was that I did not toe the Party line.  I hope 
those days are gone, and that, should a developer happen along who 
contributes to alt.design, and expresses a desire to continue to work on 
it, he or she will be granted committer status with the now customary 
alacrity.
Sorry, I don't see much value in using pull parsing instead of
push parsing either. Now if you could get footnote separators
to appear in HEAD, or TR14 line breaking, or side floats...
J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Glen Mazza]

Peter,

The decision to stop work in trunk--and to place all
efforts into alt-design, should be put to a vote first
by the committers.  I'm quite reluctant for us to be
putting all our eggs in one basket at this time.  

I want alt-design to "win" because it became the
better implementation over an optimized trunk
code--not because we kept purposefully trunk
incomplete, buggy and unoptimized so that six months
down the road we had no other choice but to go to
alt-design.  

And if we kept trunk unimproved, what would happen
should the "lead developer" on alt-design find out he
doesn't have the time to complete his work?  We've
been in this situation before--this is a very
time-consuming project and it could happen.  We need a
fallback.

What *does* work is continually modularizing the code
so alt-design can better fit in component-by-component
where possible, and also incorporating your findings
within the trunk design so we can continually reduce
the delta between the two branches.

(Besides...some of us happen to enjoy "hacking code"
and optimizing it...Don't take away our fun!  ;)

Glen

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Victor Mote wrote:
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Glen Mazza]

Peter--I've been *trying* to contribute to your
alt.design--I respond as best I can to your postings.

Many of us (but by no means all) are just not yet in
your order-of-magnitude of knowledge yet...

Glen

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> and that, should a developer
> happen along who 
> contributes to alt.design, and expresses a desire to
> continue to work on 
> it, he or she will be granted committer status with
> the now customary 
> alacrity.
> 
> Peter
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Nomination of Glen Mazza as committer

[Arved Sandstrom]

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> Sent: June 16, 2003 5:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Nomination of Glen Mazza as committer
> 
> 
> Victor Mote wrote:
> > Being the greenest committer, I had hoped to defer this 
> nomination to a more
> > senior developer. However, I think it is appropriate to 
> nominate Glen Mazza
> > for committer status. He is knowledgeable and thoughtful, and I 
> think it is
> > in the interest of the project to turn him loose so that he can 
> keep working
> > without having to wait on us.
> 
> +1

And also +1.

Arved

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Nomination of Glen Mazza as committer

[Victor Mote]

Peter B. West wrote:

> plus comments.  I am happy to see new committers come into the project.
>   I recall, however, that it took me a year to gain that status, a year
> during which I wrote a considerable amount of code which I maintained in
> my ISP account.  My crime was that I did not toe the Party line.  I hope
> those days are gone, and that, should a developer happen along who
> contributes to alt.design, and expresses a desire to continue to work on
> it, he or she will be granted committer status with the now customary
> alacrity.

I'm going to respond to your (prior) emails in turn, but this one deserves
special attention. It is not my intention to institute or encourage a policy
of "customary alacrity", but rather "timely attention". If Bill Joy or James
Duncan Davidson asked to be made committers on this project, I would vote
for it today. I have an 11-year old son who wants to be a Java programmer,
and he'll have to wait a bit before getting my vote. I wasn't around for the
year of which you speak, and I don't know where you fall on that continuum.
My only point is that the timing for Glen seems appropriate.

With regard to a Party Line, please allow me to briefly philosophize. Civil
societies (of which FOP development can be considered one) have both
centrifugal and centripetal forces at work. In general, the centrifugal
forces are that we each like to have things done our way, and the
centripetal forces are an acknowledgement that we are unable to achieve the
goal without help from others. If one person were able to complete a project
the size of FOP, we would all be better off to delegate that task to that
one person and let them do the job. We know that can't happen. We also know
that if Jeremias is headed north and I am headed south, a lot of energy is
expended, but not much progress is made. So, yes, there is a Party Line, a
common consensus about how to get where we want to go. No, I do not want FOP
rewritten in Fortran. No, I do not want FOP to output everything to RTF,
then convert it to PDF. And no, frankly, I don't want the layout process
pulling the parsing (until I can be persuaded of a substantial benefit).
Yes, there is a Party Line, and there must be. I am at odds with certain
pieces of it. In the long run, I will either 1) persuade a change in it, 2)
show a working implementation that is better, 3) be persuaded myself to
change, 4) live with it the way it is because it is better than
alternatives, or 5) go away and do something else. That is the nature of
civil societies. As long as #5 is an option, there is nothing tyrannical
about it.

I will address the merits of your proposals in separate messages on those
threads. In the meantime, AFAIK, everyone on this team values your efforts.
I am sure that no one is intentionally slighting you. I have about 20 hours
a week to spend on FOP, and for my feeble brain that is just not enough
bandwidth to comprehensively evaluate every proposal on the table.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Glen Mazza]

Any committer from Chicago?  A +6 or +7 would be
really fantastic right now!!!  ;)

Thanks, virtual team, for all the endorsements.  I am
painfully aware that others had to contribute far more
and for a longer time to become committers--I'll work
on reducing that delta over the upcoming weekends!

Regards,
Glen


--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> 
> +1
> 
> J.Pietschmann
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: FOTreeBuilder/ElementMapping change ideas

[Victor Mote]

Glen Mazza wrote:

> The decision to stop work in trunk--and to place all
> efforts into alt-design, should be put to a vote first
> by the committers.  I'm quite reluctant for us to be
> putting all our eggs in one basket at this time.  

AFAIK, there is no such proposal on the table from Peter or anyone else.

Victor Mote

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: FOTreeBuilder/ElementMapping change ideas

[Victor Mote]

Peter B. West wrote:

> I'm pleased and surprised to hear that most of your design questions
> have been answered.  What scope of design are you talking about?

Ah, a good question. The scope of design on which I am currently working is:
1) refactor the startup procedures (Driver) into Session, Document,
RenderContext, and RenderTask objects for greater reusability of each of
those items.
2) refactor the redesign layout into a component that can very easily be
replaced by some other layout engine.
3) drop the old (maintenance branch) engine into the redesign code, if
possible, using the same concept described in #2 above.

You are correct that not all of my layout design questions have been
answered. However, I am convinced that completing the above work is the
quickest way to getting those questions answered, because it will get our
common code base components (those other than layout) common again, and get
layout to the place where we can have more than one option. It will take me
a while to get through this big-picture work before I can start on layout
again.

> I am a little more disturbed to hear that alt.design is once again my
> baby.  I have been posting here intermittently over the past few weeks
> with design notes that explore the implications of my discoveries about
> the impact of some particulares of the Rec on my current properties
> handling, the implications for the layout of those issues and the
> integration of alt.design, and some general questions of layout design.

Here is my frank take on the alt.design work: I /think/ you are on the right
track as far as properties go. In a general way I understand the problems
you have described about actual layout placement driving some of the
property creation. I am inclined to think that these problems can be solved
in layout itself rather than trying to make layout drive the FO tree
creation. However, I may be wrong, and at some point (not today) I may try
to get better up to speed on this issue. I am not very excited at all about
the pull parsing concept. It took me a while, but I finally got generally
comfortable with the way our parsing now works, and went to the trouble of
documenting why in our developer doc, with the hope that we can reach
consensus around it, and prevent future new developers from stumbling there.

The reason I have not jumped into the alt.design work is that I do not see
it as /the/ most important place to spend my efforts. That does not mean
that it is not important, just that it is not as high on my priority list as
it is on yours.

With that said, I am eager to see the working code from your efforts (even
the ones that I am inclined to disagree with), and to hear how they will
benefit the project. Until there are pieces of alt.design that are ready to
be merged into the trunk, it all seems like speculation. And rest assured
that I will reserve judgment about all of it until that time -- I kick
myself about 10 times a day as I discover things that I think I should have
known before.

> In making those notes, I have been at pains to illustrate my points with
> either new diagrams or reference to existing ones.  I have gone to those
> lengths because I an anxious to communicate my ideas as accessibly as
> possible.  When I was working on the properties implementation, I found
> that my attempts to explain what I was doing were met with blank
> incomprehension.  I am trying more diligently to circumvent such a
> situation now.
>
> However, it seems that I am still working in something of a vacuum.  I
> have had a little feedback, but it did not relate specifically to the
> possible impact of my ideas or the alt.design properties integration, on
> the design of layout.

I freely admit that I have not yet grasped why layout should affect
properties. I understand that marker properties need to be resolved at
layout time, but it seems like the property in the FO tree then becomes the
integer equivalent of "to be resolved".

> All of this may simply be because my comments are not considered
> relevant.  Nonetheless, I believe that the *kind* of design commentary I
> am making is of great value in the development of the design of layout.
> irrespective of the particulars of my work.  One of the problems of
> getting more people involved in the redesign work is the opacity of the
> process.  It seems to me that the redesign documentation is, to too
> great an extent, simply the code.  I say this in spite of the other
> documentation that has been done.

Your comments are relevant. However, I frankly see issues like pull parsing
to be a net distraction to the project, so I admit that I don't pay much
attention to them. However, I think it is a worthy goal for the project to
eventually resolve alt-design one way or another, and since you seem
somewhat determined to bring the issue to a head, perhaps now is a good
time. If you will present your ideas in the form of a proposal(s) to be
voted on, I assure you that I will spend whate

cvs commit: xml-fop/src/documentation/content/xdocs output.xml

[vmote]

vmote   2003/06/16 16:00:54

  Modified:src/documentation/content/xdocs output.xml
  Log:
  Clean up content a bit for Text Renderer. Add comments about optimal settings to 
minimize spacing problems. Contributed by Vincent Illiano (see 
http://marc.theaimsgroup.com/?l=fop-dev&m=104687730831749&w=2).
  
  Revision  ChangesPath
  1.12  +12 -9 xml-fop/src/documentation/content/xdocs/output.xml
  
  Index: output.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/output.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- output.xml22 Apr 2003 18:24:28 -  1.11
  +++ output.xml16 Jun 2003 23:00:54 -  1.12
  @@ -277,19 +277,15 @@
   
 TXT
   
  -Text as you could imagine does not work very well. It is an output format
  -that you should expect bad results. The main purpose of this is to get
  -a quick and dirty view of the document and the text inside it.
  -
  -
  -The TXTRenderer is a FOP renderer that produces plain ASCII text output
  +The text renderer produces plain ASCII text output
   that attempts to match the output of the PDFRenderer as closely as
   possible. This was originally developed to accommodate an archive system
  -that could only accept plain text files. Of course when limited to plain
  -fixed pitch text the output does not always look very good.
  +that could only accept plain text files, and is primarily useful for getting
  +a quick-and-dirty view of the document text. The renderer is very limited,
  +so do not be surprised if it gives unsatisfactory results.
   
   
  -The TXTRenderer works with a fixed size page buffer. The size of this
  +The Text renderer works with a fixed size page buffer. The size of this
   buffer is controlled with the textCPI and textLPI public variables.
   The textCPI is the effective horizontal characters per inch to use.
   The textLPI is the vertical lines per inch to use. From these values
  @@ -298,6 +294,13 @@
   Graphic elements (lines, borders, etc) are assigned a lower priority
   than text, so text will overwrite any graphic element representations.
   
  +Because FOP lays the text onto a grid during layout, there are frequently 
extra or missing spaces between characters and lines, which is generally 
unsatisfactory.
  +Users have reported that the optimal settings to avoid such spacing problems 
are:
  +
  +  font-family="Courier"
  +  font-size="7.3pt"
  +  line-height="10.5pt"
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

J.Pietschmann wrote:
Peter B. West wrote:

The easiest way to proceed is to hack existing code.


Text-align="justify" is broken in HEAD. Challenge: make
it work. Right aligning works, so this should be easy...
I bet quite a few people looked at it and decided there
are less challenging but equally important (to them)
things to do.


If I could get some time, I probaly could pull it.
Joerg,

I'm not sure what you meant, but my comment stands.  Whatever it is you 
need time for (fixing justify or fixing FOP), it seems to me that the 
only way you will get the time is to limit your other committments and 
focus your considerable energies.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Comments

[Peter B. West]

J.Pietschmann wrote:
Peter B. West wrote:

 I recall, however, that it took me a year to gain that status, a year 
during which I wrote a considerable amount of code which I maintained 
in my ISP account.  My crime was that I did not toe the Party line.  I 
hope those days are gone, and that, should a developer happen along 
who contributes to alt.design, and expresses a desire to continue to 
work on it, he or she will be granted committer status with the now 
customary alacrity.


Sorry, I don't see much value in using pull parsing instead of
push parsing either. Now if you could get footnote separators
to appear in HEAD, or TR14 line breaking, or side floats...
So we shall disagree.  That is not my point.  Is disagreement allowed?

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Ascii file generation questions

[Victor Mote]

Art (Welch?) wrote:

> better than an overwrite). One of the original constraints when the
> TXTRenderer was developed was that the text output fit within fixed page
> sizes (fixed number of rows/columns). Depending on your application, this
> may not be important. Perhaps a "mode" could be added to preserve text
> (versus preserving layout). The only consolation I have had with regard to
> the TXTRenderer is that I find its output superior to many commercial
> applications' lame text output (IMHO).

I have had this thought as well, basically to add a "rawtext" output option
that would not be paginated. It would basically be another structured output
option (similar to MIF and RTF), and would seem to be very easy to get
working at a basic level (tables, etc. are extra). Except for line breaks
(which should probably be optional), it really wouldn't add much value over
using XSLT to spit out the content.

Also, Vincent, I just added some content to the doc that was gleaned from an
email that you wrote several months ago, that documents the optimal settings
needed to avoid line overwrite, etc. Thanks for that useful information.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

Glen,

I hope I did not leave the impression that stopping work on trunk was 
what I was seeking.  I thought it was generally agreed some time ago 
that my work on properties should be integrated, for the simple reason 
that it is smaller and faster.  It seems now that there are 
philosophical differences in the group about at least two issues - pull 
vs push parsing and design methodology (or lack of it).

[ Note that my properties handling runs faster in spite of the fact that 
pull parsing is *inherently* slower that push parsing.  It is 
considerable smaller in spite of the fact that pull parsing *inherently* 
consumes more objects than push parsing.

I'm committed to it because it makes for more readily understood code. 
In this I agree with Microsoft, surprisingly enough. ]

Given that I was talking about the problems which arise from 
integration, including problems which I have since detected in my own 
properties implementations, I am surprised that I was misunderstood as 
seeking a switch to alt.design.

However, much of the burden of what I did say relates to the issue of 
what happens when the lead designer can't do it any more.  I'm the one 
who wants better, moer readily undestandable documentation, better, more 
readily understood design discussion, better,  more readily understood 
documentation of the implementation details.  If you don't believe that, 
try looking at my (incomplete) documentation of alt.design, and my 
contributions in this list to design discussions.

The whole point of my urgings and example is to make it easier for new 
developers to come up to speed.  Note that, indeed, "we have been in 
this situation before."  We still are.

I repeat that hacking on the code is easier and more immediately 
rewarding than thinking through the design.  The approaches are not 
mutually exclusive, and must be mixed, I think.  But, here has been too 
much of the former and too little of the latter, IMO.

Welcome aboard.

Peter

Glen Mazza wrote:
Peter,

The decision to stop work in trunk--and to place all
efforts into alt-design, should be put to a vote first
by the committers.  I'm quite reluctant for us to be
putting all our eggs in one basket at this time.  

I want alt-design to "win" because it became the
better implementation over an optimized trunk
code--not because we kept purposefully trunk
incomplete, buggy and unoptimized so that six months
down the road we had no other choice but to go to
alt-design.  

And if we kept trunk unimproved, what would happen
should the "lead developer" on alt-design find out he
doesn't have the time to complete his work?  We've
been in this situation before--this is a very
time-consuming project and it could happen.  We need a
fallback.
What *does* work is continually modularizing the code
so alt-design can better fit in component-by-component
where possible, and also incorporating your findings
within the trunk design so we can continually reduce
the delta between the two branches.
(Besides...some of us happen to enjoy "hacking code"
and optimizing it...Don't take away our fun!  ;)
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Peter B. West]

Glen,

I did notice your interest, and I appreciate it.

Peter

Glen Mazza wrote:
Peter--I've been *trying* to contribute to your
alt.design--I respond as best I can to your postings.
Many of us (but by no means all) are just not yet in
your order-of-magnitude of knowledge yet...
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

startup refactoring

[Victor Mote]

FOP Developers:

I did a dry run of the startup refactoring (Session, Document, etc.) work
yesterday & this morning, and am satisfied that the concepts work. Here are
some comments:

1. I am going to start committing changes, hopefully this evening. Much of
the work is refactoring, but there are some substance changes as well,
specifically to allow multiple output options, multiple documents, etc. I
have therefore decided to implement it as a series of self-contained
changes, rather than dropping the entire change in at once. This will make a
better doc trail. Let me know if you object.

2. Logging. During the dry run, I realized that I don't know whether we want
to have logging for a Session, or for each Document, or even at some finer
level of granularity. Session will be implemented as a singleton, so if we
only need logging at that level, then a static construct can be used to get
logging from /anywhere/ without adding anything. Otherwise, I'll add logic
that allows the Document object to either be directly accessed or computed
(by going up the object hierarchy) to get the logger. That seems more
desirable to me than implementing logging in all of the classes, but perhaps
I am missing something there.

Victor Mote (mailto:[EMAIL PROTECTED])
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650
Fax   +1 (720) 293-0044


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Nomination of Glen Mazza as committer

[Peter B. West]

Victor,

As to the necessary conditions for committer status, "Shall we take that 
as read, darling?"*  The question remains, "If a another developer 
happens along who 1) is persuaded that alt.design is worthwhile, and 2) 
sees the existing properties code as a working implementation that is 
better, and 3) wants to work on alt.design more or less exclusively, 
will he/she be admitted to committer status with the - all other things 
being equal - now customary alacrity?"

Will those existing committers who are not interested in alt.design 
allow it to flourish in the (unlikely) event that it attracts the 
interest of other developers, or will the Party line, necessary as that 
may be considered, dictate the such a development be resisted?

Peter

* John Cleese, in "The Meaning of Life"

Victor Mote wrote:
Peter B. West wrote:


plus comments.  I am happy to see new committers come into the project.
 I recall, however, that it took me a year to gain that status, a year
during which I wrote a considerable amount of code which I maintained in
my ISP account.  My crime was that I did not toe the Party line.  I hope
those days are gone, and that, should a developer happen along who
contributes to alt.design, and expresses a desire to continue to work on
it, he or she will be granted committer status with the now customary
alacrity.


I'm going to respond to your (prior) emails in turn, but this one deserves
special attention. It is not my intention to institute or encourage a policy
of "customary alacrity", but rather "timely attention". If Bill Joy or James
Duncan Davidson asked to be made committers on this project, I would vote
for it today. I have an 11-year old son who wants to be a Java programmer,
and he'll have to wait a bit before getting my vote. I wasn't around for the
year of which you speak, and I don't know where you fall on that continuum.
My only point is that the timing for Glen seems appropriate.
With regard to a Party Line, please allow me to briefly philosophize. Civil
societies (of which FOP development can be considered one) have both
centrifugal and centripetal forces at work. In general, the centrifugal
forces are that we each like to have things done our way, and the
centripetal forces are an acknowledgement that we are unable to achieve the
goal without help from others. If one person were able to complete a project
the size of FOP, we would all be better off to delegate that task to that
one person and let them do the job. We know that can't happen. We also know
that if Jeremias is headed north and I am headed south, a lot of energy is
expended, but not much progress is made. So, yes, there is a Party Line, a
common consensus about how to get where we want to go. No, I do not want FOP
rewritten in Fortran. No, I do not want FOP to output everything to RTF,
then convert it to PDF. And no, frankly, I don't want the layout process
pulling the parsing (until I can be persuaded of a substantial benefit).
Yes, there is a Party Line, and there must be. I am at odds with certain
pieces of it. In the long run, I will either 1) persuade a change in it, 2)
show a working implementation that is better, 3) be persuaded myself to
change, 4) live with it the way it is because it is better than
alternatives, or 5) go away and do something else. That is the nature of
civil societies. As long as #5 is an option, there is nothing tyrannical
about it.
I will address the merits of your proposals in separate messages on those
threads. In the meantime, AFAIK, everyone on this team values your efforts.
I am sure that no one is intentionally slighting you. I have about 20 hours
a week to spend on FOP, and for my feeble brain that is just not enough
bandwidth to comprehensively evaluate every proposal on the table.
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Nomination of Glen Mazza as committer

[Victor Mote]

Peter B. West wrote:

> As to the necessary conditions for committer status, "Shall we take that
> as read, darling?"*  The question remains, "If a another developer
> happens along who 1) is persuaded that alt.design is worthwhile, and 2)
> sees the existing properties code as a working implementation that is
> better, and 3) wants to work on alt.design more or less exclusively,
> will he/she be admitted to committer status with the - all other things
> being equal - now customary alacrity?"
>
> Will those existing committers who are not interested in alt.design
> allow it to flourish in the (unlikely) event that it attracts the
> interest of other developers, or will the Party line, necessary as that
> may be considered, dictate the such a development be resisted?

I have exactly one vote on such matters, so I can't speak for the whole, but
as far as I am concerned, developers such as you describe are more than
welcome to join the party. In the event that alt-design remains on a branch,
I don't think any reasonable person could object. At the point in time that
we contemplate merging to the trunk, we need to come to an agreement. In the
unlikely event that we can't come to an agreement, we always have the option
to fork the project. My purpose here is to avoid that if possible.

BTW, I hope this isn't a Peter-vs.-Victor thing. For example, I know there
are opportunities to use less memory and more speed (which you report in
alt-design) in the FO tree creation. If memory serves, we are storing the
URL for the fo: namespace in every FONode object, which should be replaced
by an integer pointing into a table. I am very open to being educated, but I
think it is fair to say that I am not persuaded on all of it yet, and I
think the burden of proof lies heavily on you. Unless pull parsing is an
integral part of the whole, I think the alt-design changes will be best
swallowed in smaller pieces.
Also, if pull parsing can be implemented in a pluggable, configurable way
(ie. choose either push parsing or pull parsing at runtime), it will have a
much better chance of being accepted. My understanding of it is that it has
a pervasive effect, making separation between the modules more difficult
instead of less. IMO, absent a /significant/ benefit that cannot be achieved
some other way, this would be a deal-killer.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: FOTreeBuilder/ElementMapping change ideas

[Victor Mote]

Glen Mazza wrote:

> No response on the below questions from any committer,
> and I'm concerned about the drop-off on the FOP-DEV
> mailing list over the past few weeks (at an
> extrapolated 170 emails on FOP-DEV for the month, this
> would be our lightest month since Dec. 1999!)  

Well, I think you solved that "problem" :-)

Victor Mote

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOTreeBuilder/ElementMapping change ideas

[Glen Mazza]

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> 
> I thought it was generally
> agreed some time ago 
> that my work on properties should be integrated, for
> the simple reason 
> that it is smaller and faster.  

Exactly!  Now you're talking my language--"smaller and
faster"--i.e., something that will generate more
same-size reports than trunk will.

I want it so that when we get performance complaints
such as Brian Minchau/Xalan recently did
(http://marc.theaimsgroup.com/?l=xalan-dev&m=105552092525811&w=2)
we can confidently state that FOP has the best design
possible.

However, per the centripetal/centrifugal discussion of
Victor (*very* interesting, BTW), we need to see
*proof* that it is faster, and to help do that, we
should make the code more modular.



That's why I want ElementMappings out of apps package
and back into the FOTreeBuilder class.  This way, when
someone like you has a competing design--no more
ElementMappings, use push/pull parsers, widgets,
abacuses, chickens, whatever--you only have to change
FOTreeBuilder, and not simultaneously 57 places
throughout the code.  It makes it easier to
test/compare different implementations, and less
mortifying for such changes to be made because fewer
classes need updating.



Secondly, as I mentioned earlier about applying your
findings, you've already confirmed for me my
suspicions that user-defined ElementMappings won't
work because the semantics of those mappings would not
be understood by the rest of the code anyway (please
contradict me here if I'm wrong)--Great, for 1.0, in
addition to moving the DefaultMappings to
FOTreeBuilder, we can dispense with the code that
allows for users to add on their own mappings.  Me
applying your findings now--even if in a different
implementation--saves you the "Hey, we can't go to
push/pull parsers because we'll lose user-defined
ElementMappings!!!" argument later.  (You'll still
have to win the faster argument though... ;)

> I repeat that hacking on the code is easier and more
> immediately 
> rewarding than thinking through the design.  The
> approaches are not 
> mutually exclusive, and must be mixed, I think. 

I agree that "hacking" the code would be useless for
you, because you understand it--but I need to work on
the code/refactor it/keep it clean (I have fun with a
local version of FOP) just to understand how FOP
works.  I have apps mostly understood and am now
looking at the layout package.  This helps me hold
more better conversations with the team.  

> But, here has been too 
> much of the former and too little of the latter,
> IMO.

Agreed.  I'm happily looking forward to the day when I
can debate you on all implementation issues--even trip
you up every now and then--until then, I need to keep
working on the code to understand it more, and yes,
reading your writings more.

Glen


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20827] New: - Style and weight supported use one Normal TureType Font.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20827

Style and weight supported use one Normal TureType Font.

   Summary: Style and weight supported use one Normal TureType Font.
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


CJK TureType font has only one Font style: normal normal, because of LARGE 
CHARACATER SET. So FOP can not render a italic font using a Normal Normal font.

In Java2, Local fonts can be used, and you can create a Italic font derive from 
a normal font. And so in Arcobat on windows. Can FOP extends such ability in 
farther version??

I understand that FOP can not transform Font Style automatically, it may be due 
to some other Error(??).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: startup refactoring

[Glen Mazza]

--- Victor Mote <[EMAIL PROTECTED]> wrote:
> 
> 1. I am going to start committing changes, hopefully
> this evening. Much of
> the work is refactoring, but there are some
> substance changes as well,
> specifically to allow multiple output options,
> multiple documents, etc. I
> have therefore decided to implement it as a series
> of self-contained
> changes, rather than dropping the entire change in
> at once. This will make a
> better doc trail. Let me know if you object.
> 

Shouldn't be a problem (we can always go back to the
old code if it's a disaster!)  When you're done, I
still would like to get the LayoutHandler and
StructureHandler classes out of the apps package
though (Bug 20397, although on these new classes)--any
objections from anyone on this part?

Glen


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/java/org/apache/fop/tools/anttasks Fop.java

[vmote]

vmote   2003/06/16 19:46:56

  Modified:src/java/org/apache/fop/apps AWTStarter.java
CommandLineOptions.java CommandLineStarter.java
Driver.java FOInputHandler.java InputHandler.java
PrintStarter.java TraxInputHandler.java
XSLTInputHandler.java
   src/java/org/apache/fop/image XMLImage.java
   src/java/org/apache/fop/servlet FopPrintServlet.java
FopServlet.java
   src/java/org/apache/fop/svg SVGElementMapping.java
SVGUserAgent.java
   src/java/org/apache/fop/tools TestConverter.java
   src/java/org/apache/fop/tools/anttasks Fop.java
  Added:   src/java/org/apache/fop/apps Session.java
  Log:
  1. Copy apps.Driver to apps.Session.
  2. Fix all references to use Session instead of Driver.
  3. Keep contents of "Services" class, but remove the class definition itself so that 
it can be used by both Driver and Session.
  4. Deprecate Driver.
  
  Revision  ChangesPath
  1.3   +15 -15xml-fop/src/java/org/apache/fop/apps/AWTStarter.java
  
  Index: AWTStarter.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/AWTStarter.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- AWTStarter.java   14 May 2003 08:11:31 -  1.2
  +++ AWTStarter.java   17 Jun 2003 02:46:55 -  1.3
  @@ -3,34 +3,34 @@
* 
*The Apache Software License, Version 1.1
* 
  - * 
  + *
* Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
  - * 
  + *
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
  - * 
  + *
* 1. Redistributions of source code must retain the above copyright notice,
*this list of conditions and the following disclaimer.
  - * 
  + *
* 2. Redistributions in binary form must reproduce the above copyright notice,
*this list of conditions and the following disclaimer in the documentation
*and/or other materials provided with the distribution.
  - * 
  + *
* 3. The end-user documentation included with the redistribution, if any, must
*include the following acknowledgment: "This product includes software
*developed by the Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowledgment may appear in the software itself, if
*and wherever such third-party acknowledgments normally appear.
  - * 
  + *
* 4. The names "FOP" and "Apache Software Foundation" must not be used to
*endorse or promote products derived from this software without prior
*written permission. For written permission, please contact
*[EMAIL PROTECTED]
  - * 
  + *
* 5. Products derived from this software may not be called "Apache", nor may
*"Apache" appear in their name, without prior written permission of the
*Apache Software Foundation.
  - * 
  + *
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
  @@ -42,12 +42,12 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
* 
  - * 
  + *
* This software consists of voluntary contributions made by many individuals
* on behalf of the Apache Software Foundation and was originally created by
* James Tauber <[EMAIL PROTECTED]>. For more information on the Apache
* Software Foundation, please see .
  - */ 
  + */
   package org.apache.fop.apps;
   
   //FOP
  @@ -76,7 +76,7 @@
   public class AWTStarter extends CommandLineStarter {
   private PreviewDialog frame;
   private Translator translator;
  -private Driver driver;
  +private Session session;
   private XMLReader parser;
   
   /**
  @@ -101,8 +101,8 @@
   AWTRenderer renderer = new AWTRenderer(translator);
   frame = createPreviewDialog(renderer, translator);
   renderer.setComponent(frame);
  -driver = new Driver();
  -driver.setRenderer(renderer);
  +session = new Session();
  +session.setRenderer(renderer);
   parser = inputHandler.getParser();
   if (parser == null) {
   throw new FOPException("Unable to create SAX parser");
  @@ -115,10 +115,10 @@

Re: FOTreeBuilder/ElementMapping change ideas

[Peter B. West]

Victor and fopdevs,

See below...

Victor Mote wrote:
Peter B. West wrote:


I'm pleased and surprised to hear that most of your design questions
have been answered.  What scope of design are you talking about?


Ah, a good question. The scope of design on which I am currently working is:
1) refactor the startup procedures (Driver) into Session, Document,
RenderContext, and RenderTask objects for greater reusability of each of
those items.
2) refactor the redesign layout into a component that can very easily be
replaced by some other layout engine.
This is a very nasty one.  The maintenance and the HEAD code may 
encourage you to believe that it is not.  What I am looking to do next 
with alt.design is to make the resolution of FO nodes occur in the 
context of the Area into which the FO node is being composed.  I.e., to 
intimately link FO tree and Area tree construction.  I am intending to 
do this because I believe it is the only comprehensive and clean 
solution to the problem.

3) drop the old (maintenance branch) engine into the redesign code, if
possible, using the same concept described in #2 above.
You are correct that not all of my layout design questions have been
answered. However, I am convinced that completing the above work is the
quickest way to getting those questions answered, because it will get our
common code base components (those other than layout) common again, and get
layout to the place where we can have more than one option. It will take me
a while to get through this big-picture work before I can start on layout
again.

I am a little more disturbed to hear that alt.design is once again my
baby.  I have been posting here intermittently over the past few weeks
with design notes that explore the implications of my discoveries about
the impact of some particulares of the Rec on my current properties
handling, the implications for the layout of those issues and the
integration of alt.design, and some general questions of layout design.


Here is my frank take on the alt.design work: I /think/ you are on the right
track as far as properties go. In a general way I understand the problems
you have described about actual layout placement driving some of the
property creation. I am inclined to think that these problems can be solved
in layout itself rather than trying to make layout drive the FO tree
creation.
See above.

  However, I may be wrong, and at some point (not today) I may try
to get better up to speed on this issue. I am not very excited at all about
the pull parsing concept. It took me a while, but I finally got generally
comfortable with the way our parsing now works, and went to the trouble of
documenting why in our developer doc, with the hope that we can reach
consensus around it, and prevent future new developers from stumbling there.
I have made some comments about "the way our parsing now works" in 
another post.

The reason I have not jumped into the alt.design work is that I do not see
it as /the/ most important place to spend my efforts. That does not mean
that it is not important, just that it is not as high on my priority list as
it is on yours.
With that said, I am eager to see the working code from your efforts (even
the ones that I am inclined to disagree with), and to hear how they will
benefit the project. Until there are pieces of alt.design that are ready to
be merged into the trunk, it all seems like speculation.
Agreed, which is why I a going to follow through on the implications of 
the Rec rather than try to integrate a model of FO tree parsing and 
construction which I know to be flawed.

 And rest assured
that I will reserve judgment about all of it until that time -- I kick
myself about 10 times a day as I discover things that I think I should have
known before.
...
I freely admit that I have not yet grasped why layout should affect
properties. I understand that marker properties need to be resolved at
layout time, but it seems like the property in the FO tree then becomes the
integer equivalent of "to be resolved".
Marker processing is a clear example of the serendipitous advantages of 
pull parsing.  It is the pull parsing design that makes the resolution 
of markers in static-content a near-trivial exercise.  If you refer back 
to the diagrams I posted about marker processing, you will see that 
streams of FoXMLEvents are being buffered in two places.  If the input 
buffer is a parameter, the normal FO tree building processes can be 
invoked on such buffers, which can also be dynamically switched to 
include the marker subtrees from earlier fo:marker processing.


All of this may simply be because my comments are not considered
relevant.  Nonetheless, I believe that the *kind* of design commentary I
am making is of great value in the development of the design of layout.
irrespective of the particulars of my work.  One of the problems of
getting more people involved in the redesign work is the opacity of the
process.  It seems to me that the redesi