RE: Fonts

2004-05-25 Thread arnd . beissner

Victor Mote [EMAIL PROTECTED] wrote
on 25.05.2004 01:46:50:

 However, since these same fonts could also be used by the PostScript
 renderer, or the Print or AWT renderers (assuming that the pfb is
available
 as well), I don't see a need to duplicate their definitions, or metrics,
or
 anything for each one of these environments, which is what it sounds
like
 you might be suggesting.

Yes, but the base-14 fonts for example are not defined
for AWT renderers, since
*only* their metrics is publicly available. Still,
in the case of the 
base 14-fonts you can really argue that you want to
extend the PDF model of
(these fonts are always there). Just note that on
many systems you are out
of luck with - for example - the Zapf Dingbats fonts.

 It should be sufficient for the Renderer (or
 RenderContext) to tell what it is *capable* of doing, without having
to
 provide the actual detail. In the case of the Base-14 font metrics,
we can
 and should and do embed them within FOP itself.

In the case of an AFP renderer your model would suggest
to the formatter
that the 4 faces of Helvetica, Times Roman and Courier
are available which
they are not. At least, you would have to supply additional
information
so that the formatter could decide which of the standard
fonts is available
to which renderer.

 Why is this better than simply supplying the same font metrics at
a global
 level, and letting the Renderer or RenderContext tell what it is/is
not
 capable of processing? What would one get in return for giving up
that
 simplicity?

You would gain simplicity in another respect - you
would exactly know 
which font (and not only which *type* of font is available
to which
renderer or device (in the latter case, think about
output to different
printers from the same installation, which could have
a differing set of
device fonts).

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH


Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Simon Pepping wrote:
snip/
No exceptions. I ran Luca's test fo files successfully.
Strange how you and I always get such different results. It doesnt run with 
any file despite changing the language to en. I always get NPE on LLM:249. 
Looking at the code it would appear to be a mistake as NPE will occur if 
text-indent is not specified on any block. I tried placing a IF statement 
around this line, but got a NPE elsewhere.

I dont understand how you can run Luca's files. The NPE seem to be limited to 
LLM and TLM, which I copied complete from Luca's patch. Did you manage to 
apply the patch file with LLM/TLM, or did you copy the complete files? There 
must be some differences in our code, or am I going mad?!?

snip/
I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
I have to agree that the patch is far from ready. I in no way mean to cast a 
bad light on Luca's work. Luca must be congratulated for his efforts thus far, 
but we cannot accept a patch that will take the redesign effort backwards. 
With more testing and the bugs fixed, this patch will take the redesign 
forwards with a much cleaner approach to line breaking. I hope Luca will be 
happy to work on his patch some more locally.

If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
I have to agree with Glen on this point, -1 for creating another branch. I 
have replied in more detail in another posting.

Chris



Re: Justification and line breaking

2004-05-25 Thread Luca Furini

Chris Bowditch wrote:

 Here is the stack trace, which is the same for both documents:
 [...]

 Any thoughts would be appreciated.

JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.

KnuthParagraphs (the ArrayList whose item are the different
linefeed-separated paragraphs) is initialized just before calling
startParagraph:

  ...
  // it's the first time this method is called
  knuthParagraphs = new ArrayList(); /* here it is */
  breakpoints = new ArrayList();

  // convert all the text in a sequence of paragraphs made
  // of KnuthBox, KnuthGlue and KnuthPenalty objects
  Paragraph knuthPar = new Paragraph();
  knuthPar.startParagraph();
  ...

While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):

  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...

I hope this can help you; thanks for testing my patch.

Regards
Luca




Re: Justification and line breaking

2004-05-25 Thread Luca Furini

Simon Pepping wrote:

 I changed the constructor call as well. I changed the logger calls
 from getLogger() to log. log is a member of
 AbstractLayoutManager. These are changes applied by Glen, and
 apparently Luca made his diff before they were applied.

Yes; more exactly, I forgot to apply these changes to the code I was
already working on.
To avoid this kind of problems, I will try to keep my code updated.

 I am not surprised that your complex document did not run well. If I
 understand the situation well, then the patch works for LineLM with
 TextLM childLMs. It does not work with any other childLM. I expect the
 other childLMs to use the null implementation of getNextKnuthElement()
 and therefore to contribute no areas.

You are completely right; by the way, what other child LMs could the LLM
have?

 I do not believe that the patch is mature for committing to the trunk
 code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...

I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.

I'll work on this patch for some more time, and I'll let you know of the
progress.

Regards
Luca




Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Peter B. West wrote:
snip/
Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree immediately 
before a branch.
Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel the 
project is at the wrong stage in its development for another branch right now. 
Branches invariably mean splitting development focus. Right now I want to 
focus on fixing the High priority issues with layout so we can do a release. 
If we flail around for another year or so then FOP may be dead in the water as 
other projects overtake it.

Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Luca Furini wrote:
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.
I have proved that textIndent is definitely null when it is not specified on 
the block.

snip/
While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):
I assume you mean the LLM constructor?
  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...
and if blockProps.firstIndent returns null? Which it appears to be if the user 
doesnt specify on a block.

I hope this can help you; thanks for testing my patch.
After adding an IF test around the code that uses textIndent to avoid NPE, I 
then get the following error:

25-May-2004 09:11:43 org.apache.fop.layoutmgr.LineLayoutManager getNextBreakPoss
WARNING: No set of breaking points found with maxAdjustment = 1.0
Exception in thread main java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:385)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
at org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss(FlowLayou
tManager.java:81)
Thanks,
Chris



Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
Luca Furini wrote:
You are completely right; by the way, what other child LMs could the LLM
have?
I'm just guessing, but I think anything that can appear inline, i.e. 
hyperlinks, leaders, etc. Block level stuff like Tables and graphics can not 
be children of the LLM.

I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...
I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.
No need to apologize or thanks us, your efforts are most appreciated.
I'll work on this patch for some more time, and I'll let you know of the
progress.
Thank you, please let us know if you need any assistance or further feedback,
Chris



Commits

2004-05-25 Thread Chris Bowditch
Team,
thanks to everyone who agreed to hold off commits until the fate of Luca's 
patch had been decided. I think everyone is in agreement that this first patch 
needs more work, so I will re-sync with CVS. Therefore, it is safe to make 
commits to HEAD once more.

Thanks,
Chris



Re: can't find default configuration file

2004-05-25 Thread Chris Bowditch
Clay Leeds wrote:
BTW, Anyone else seeing sporadic mail issues? I didn't actually 
*receive* Andreas' message. (I noticed in MARC, and am responding before 
I go home).
Hi Clay - I noticed that the mailing lists were very slow yesterday, with 
responses appearing in MARC well before I received them. Seems to be back to 
normal today though.

Chris



Re: Fixing break-* properties

2004-05-25 Thread Chris Bowditch
Andreas L. Delmelle wrote:
Hi Andreas,
its great to have you trying to help with layout.
Adding the necessary activation code to the FObjs to pass these properties
to Layout is easy enough, but I'm still having a bit of difficulty in
'seeing' what needs to be done to handle this in the respective LMs
getNextBreakPoss()... How is LayoutContext involved in this (or isn't it)?
Well I believe you need to create a BP with the FORCE flag set and watch for 
this in the PageLM.

Chris



RE: Fonts

2004-05-25 Thread Victor Mote
Arnd Beißner wrote:

Arnd
Yes, but the base-14 fonts for example are not defined for AWT
renderers, since 
*only* their metrics is publicly available. Still, in the case of
the 
base 14-fonts you can really argue that you want to extend the PDF
model of 
(these fonts are always there). Just note that on many systems you
are out 
of luck with - for example - the Zapf Dingbats fonts. 
/Arnd

Victor
I don’t work with the AWT renderer, but it *should* be able to use the
base-14 fonts, assuming that the user has installed the font (not just the
metrics) on their system. It is true that only the metrics for base-14 fonts
are *freely* available, but the outlines *can* be licensed. In fact, I am
pretty sure they are all included in Adobe's Type1 version of its Type
Basics:
http://www.adobe.com/type/browser/P/P_934.jhtml

Your point is well taken that not all fonts are usable everywhere, but I do
like the idea of letting the *user* decide what those limitations are. For
example, in the example you gave of the device using bitmapped fonts, a user
might want to build PDF files at client machines that get queued up for a
machine that drives the printer itself. I think it is a good thing for
them to be able to do this. It is true that the view from within Acrobat
Reader is going to look different from the printed output, but I want to be
careful about artificially limiting the possibilities.
/Victor

Arnd
  Victor
 It should be sufficient for the Renderer (or
 RenderContext) to tell what it is *capable* of doing, without
having to
 provide the actual detail. In the case of the Base-14 font
metrics, we can
 and should and do embed them within FOP itself.
  /Victor

In the case of an AFP renderer your model would suggest to the
formatter 
that the 4 faces of Helvetica, Times Roman and Courier are available
which 
they are not. At least, you would have to supply additional
information 
so that the formatter could decide which of the standard fonts is
available 
to which renderer. 

  Victor
 Why is this better than simply supplying the same font metrics at
a global
 level, and letting the Renderer or RenderContext tell what it
is/is not
 capable of processing? What would one get in return for giving up
that
 simplicity?
  /Victor

You would gain simplicity in another respect - you would exactly
know 
which font (and not only which *type* of font is available to which 
renderer or device (in the latter case, think about output to
different 
printers from the same installation, which could have a differing
set of 
device fonts). 
/Arnd  

OK, but doesn't this mean that now the user has to write a subclass of some
Renderer in order to manage his fonts? It seems like a lot of this can be
handled in the font configuration side of things, which allows it to be more
easily accessible by the user.

In the example you give, the worst case scenario is that the AFP device gets
a document it can't handle or that looks awful when it is output. It is
totally within the user's ability to prevent and correct this. So really
what we are talking about is how to prevent the user from doing something
stupid. Even this can be prevented by forcing the user to use a font
configuration that only contains the fonts available.

Nevertheless, I have no objection in principle to giving the Renderer this
level of control if it needs or wants it. Here is what I propose -- the
forayFont API design has an interface for a FontConsumer, which the client
application must supply when it is accessing font services. We'll just add a
method, something like:
boolean canProcessFontFamily(String fontFamily)
 /* or perhaps the following, which would allow
FontConsumer to query the Font in more detail
about itself before deciding */
boolean canProcessFont(Font font)  

The Renderer will need to simply respond false when a font is presented
that it doesn't know how to handle. The font system can then throw an
exception back to the client application saying that the Renderer has
rejected the font.

This would *allow*, but not really *require* a Renderer to manage fonts at
the level of detail that you envision. So most Renderers could simply:
boolean canProcessFont(Font font)  {
return true;
}

I have added some comments regarding this to the FontConsumer section:
http://foray.sourceforge.net/module/font/index.html#api-design

This seems to address both of the competing concerns:
* your major concern that the Renderer have more control
* my major concern that fonts and font logic be removed from the
Renderers

It also seems to have the advantage of allowing the font subsystem to pull
information out of the Renderer as needed rather than having the Renderer
push everything it knows to the font system. 

Convenience branches. Was: Justification and line breaking

2004-05-25 Thread Peter B. West
Chris Bowditch wrote:
Peter B. West wrote:
snip/
Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree 
immediately before a branch.

Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel 
the project is at the wrong stage in its development for another branch 
right now. Branches invariably mean splitting development focus. Right 
now I want to focus on fixing the High priority issues with layout so we 
can do a release. If we flail around for another year or so then FOP may 
be dead in the water as other projects overtake it.
Let's sketch a procedure for things like this.  Someone proposes such a 
large patch again.  We look at and realize that it can have a 
significant impact, but is worthwhile considering.  The time frame for 
sorting it out might be anything from a week to a month or two.

Tag the tree.  Let's call it paragraph_patch.  Tell the person proposing 
the patch - let's say Luca for illustration - to build his patch again 
based on the paragraph_patch.  Luca checks out the tree using that tag. 
 When he has it in a state to be examined, he submits the patch, noting 
that his work is based on paragraph_patch.  Those interested in testing 
the patch create a branch, say paragraph_test, at the tag-point, 
paragraph_patch, checkout paragraph_test, and apply the patch.  Is there 
any problem in applying the patch?  No, because everyone is working with 
known and common versions of the files.  Is there any impact on ongoing 
commits to HEAD?  No.  The committers (and Luca) still have valid HEAD 
trees on their machines, still track and contribute to the ongoing HEAD 
development.

Let's say that Andreas commits some changes which affect Luca's work. 
Luca wants to merge them in.  He asks for a merge.  Impact on HEAD?  Ask 
Andreas if his changes have settled down.  Announce that the tree will 
be tagged at time X.  Tag the tree; paragraph_merge_pt_1.  That's it.

Meanwhile, Luca requests that the paragraph_test tree be tagged 
(before_merge_pt_1).   Disruption to HEAD - none.  He locally merges 
from paragraph_merge_pt_1 into paragraph_test, and starts to sort out 
the conflicts.  When he is done, he prepares a new patch against 
paragraph_test, which he submits.

Committers who are tracking his work apply the patch to their copies of 
the paragraph_test tree.  Disruption to HEAD - none.  Patch errors - 
none.  When the patch is ready to be applied to HEAD, the process of 
merging in from HEAD is repeated, relative to the last merge tag in 
HEAD.  Committers announce that a merge into HEAD is pending, ask that 
commits to HEAD be suspended until this is done, and tag the HEAD tree; 
before_paragraph_merge.  Luca merges locally into HEAD, and prepares a 
patch against HEAD, which he submits.  This is committed and the HEAD 
tree tagged after_paragraph_merge.  The paragraph_test branch is now 
defunct.

Note that this description covers the whole development cycle of a 
major, potentially disruptive patch, through to integration into HEAD.

Compare that to the dramas we have just been through (and are still 
going through - there seem to be two versions of HEAD out there on two 
committers' machines.)  The responsibility for developing the patch 
rests primarily on the author and secondarily on the committers who 
perform testing and feedback.  Had a procedure like this been in place, 
would the progress of Luca's patch have been more, less or equally 
disruptive?

Obviously such a procedure is only *necessary* in unusual cases, but it 
makes sense to know how it is done, and it even makes sense to practise 
doing it on short cycle changes, so that things flow smoothly when the 
big issues come along.

Just a suggestion.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


RE: can't find default configuration file

2004-05-25 Thread Andreas L. Delmelle
 -Original Message-
 From: Clay Leeds [mailto:[EMAIL PROTECTED]


Hi Clay,

 Thanks for the heads up, Andreas. I'll keep that in mind. Does this
 mean one should do something like this for Unix:


That was exactly what I meant, indeed. Not sure whether it's about the shell
script interpreting the argument as one string, but anyway, it gets passed
to the Java VM as one argument, and Java itself has no problems dealing with
long file names...


 BTW, Anyone else seeing sporadic mail issues? I didn't actually
 *receive* Andreas' message. (I noticed in MARC, and am responding
 before I go home).


As Chris mentioned, mail was indeed quite slow yesterday. Normally, I
receive postings practically instantly, give or take a few minutes, after I
send them... Yesterday, it took about 1.5 hours. Then again, it seemed to be
a general problem. Lots of delayed mails at work too.


Greetz,

Andreas



Re: Fonts

2004-05-25 Thread Clay Leeds
On May 24, 2004, at 8:57 AM, Victor Mote wrote:
Clay Leeds wrote:
On the subject of running headless, my experience has been to
pass it off to POSTSCRIPT--which, again in my
experience--runs fine headless.
Off the top of my head, I can't think of a reason that the PostScript
renderer would work and the PDF renderer not work. I run all of my 
stuff in
a headless environment to PDF, with no problems. If you can provide 
some
details here, I am very interested to identify any RenderContext
differences.

Victor Mote
Actually, we wanted to use '-print' but it was complicated by the 
'headless' problem on AIX, so we went to '-ps' (PostScript), and did a 
'cat %1 lpr' (approximation). Don't get me wrong (apologies if I gave 
that impression!)--PDF works well, unless we need SVG/Batik.

Web Maestro Clay


Re: Justification and line breaking

2004-05-25 Thread Simon Pepping
On Tue, May 25, 2004 at 09:51:28AM +0100, Chris Bowditch wrote:
 Luca Furini wrote:
 
 JThe method startParagraphs dereferences only knuthParagraphs and
 textIndent, so maybe there is a missing line concerning their 
 initialization.
 
 I have proved that textIndent is definitely null when it is not specified 
 on the block.
   ...
   bTextAlignmentLast = blockProps.textAlignLast;
   textIndent = blockProps.firstIndent; /* here it is */
   hyphProps = propMgr.getHyphenationProps();
   ...

LineLayoutManager:
protected void initProperties(PropertyManager propMgr) {
BlockProps blockProps = propMgr.getBlockProps();
textIndent = blockProps.firstIndent;
}

blockProps is initialized in the constructor of LineLM.

PropertyManager:
public BlockProps getBlockProps() {
BlockProps props = new BlockProps();
props.firstIndent = this.propertyList.get(PR_TEXT_INDENT).getLength();
return props;
}

If this.propertyList is not null, then get(PR_TEXT_INDENT) always
returns a value; if it is not specified by the user, the default value
is returned. This is true for all properties.

LengthProperty:
public Length getLength() {
return this;
}

Property:
public Length getLength() {
return null;
}

getLength(), however, may return a null value. It only returns a
non-null value if the property returned by get(PR_TEXT_INDENT) is a
LengthProperty. This should be true; I do not know a reason why it is
not true in your code.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Re: Justification and line breaking

2004-05-25 Thread Simon Pepping
On Tue, May 25, 2004 at 09:56:25AM +0100, Chris Bowditch wrote:
 Luca Furini wrote:
 
 You are completely right; by the way, what other child LMs could the LLM
 have?
 
 I'm just guessing, but I think anything that can appear inline, i.e. 
 hyperlinks, leaders, etc. Block level stuff like Tables and graphics can 
 not be children of the LLM.

I agree, all LMs for which generatesInlineAreas() returns true. That
is more or less the definition of LineLM, see its constructor. Note
that you also have to deal with descendants below children,
e.g. childLMs in an inlineLM. Other LMs may hide their content and
return a block to LineLM. For example, fo:inline-container (I guess
ICLayoutManager) may contain blocks, but hides them in a single block
from the LineLM (I am guessing a bit; have never dived so deep into
the details of these FOs; I compare them to TeX's vbox construct.)

I will see if I can get some more info on the possible descendants of
a LineLM.
 
 I thank all that spent some time looking at it and testing it, and I
 apologize if I have not been able to clearly explain what my aim was.
 
 No need to apologize or thanks us, your efforts are most appreciated.

I agree.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



CVS Karma for Simon and Clay...

2004-05-25 Thread Jeremias Maerki
...should be in place now, thanks to Ted Leung.

Jeremias Maerki



Re: CVS Karma for Simon and Clay...

2004-05-25 Thread Clay Leeds
On May 25, 2004, at 12:56 PM, Jeremias Maerki wrote:
...should be in place now, thanks to Ted Leung.
Jeremias Maerki
Sweet! Thanks to Ted Leung ( the estimable Jeremias for the 
follow-through!)

Web Maestro Clay


Re: can't find default configuration file

2004-05-25 Thread Peter B. West
Andreas L. Delmelle wrote:
That was exactly what I meant, indeed. Not sure whether it's about the shell
script interpreting the argument as one string, but anyway, it gets passed
to the Java VM as one argument, and Java itself has no problems dealing with
long file names...
Arguments enclosed in quotes, either double or single, are passed as a 
single argument to the shell script.  I'm not sure about Win CMD 
systems, but I believe that they do the same thing.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: can't find default configuration file

2004-05-25 Thread Peter B. West
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]

Hi Peter,

Arguments enclosed in quotes, either double or single, are passed as a
single argument to the shell script.  I'm not sure about Win CMD
systems, but I believe that they do the same thing.

Bam! This was the description I was looking for :)
My initial wording was a bit off, just couldn't get it expressed right
(could 've known that it would be more the OS than the shell script that
does the actual interpreting)
Andreas,
It is in fact the shell, because your CLI system interface is also the 
shell.  It interprets the arguments, then forks another shell which 
execs the binary command or interprets the shell script.  As far as I 
know, CMD works the same way.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html