ApacheCon US 2004

2004-11-19 Thread Clay Leeds
Howdy folks,
Just wanted to let you know I've removed the ApacheCon US 2004 stuff 
from the Apache FOP web site.

Hope you had fun! Wish I were there! Look forward to hearing about the 
good times 2nd or 3rd hand... :-p

Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Luca Furini
Simon Pepping wrote:

 Indeed. Something like ICLM is needed, which creates an inline area
 containing the block areas.

A block inside another block

fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block

creates 3 different paragraphs:
- Normal text
- inner block
- normal text.
and each paragraph's layout is unrelated to the other paragraphs' layout (there 
are 3 LineLM).

A block inside an inline inside a block

fo:blockNormal text fo:inline background-color=lightgreeninline text 1
fo:blockinner block/fo:block inline text 2/fo:inline normal
text./fo:block

creates:
a) 3 different paragraphs too:
- Normal text inline text 1
- inner block
- inline text 2 normal text.
or
b) a single paragraph with all the text:
- Normal text inline text 1 inner block inline text 2 normal text.
???

I'd say a), but I'm not sure.
If this were true, there should be 3 different LineLMs.

This is the LM tree at the moment:

 BlockLM1
|
 LineLM1
|
   -+-
   |||
TextLM  InlineLM  TextLM
Normal text   |  normal text.
|
   -+-
   |||
TextLM   BlockLM2 TextLM
inline text 1 | inline text 2
 LineLM2
|
 TextLM
  inner block

LineLM1 tries to have get elements from all its chidren, and fails.

But, even if it could be given the elements representing inner block, it
could layout them wrongly, because of the block properties: the inner
block could have different alignment, borders, margins, indents, 

So, the LM tree could be:

BlockLM1
  --+-
  | ||
   LineLM   BlockLM2  LineLM
   --+--|   -+-
   |   ||   | |
TextLM InlineLM  LineLM InlineLMTextLM
Normal text  ||   |normal text.
   ||   |
TextLM   TextLM  TextLM
   inline text 1   inner block   inline text 2

This modified tree can be easily obtained from the previous one:
- the new BlockLM is created
- if the LM which should add it to its children list is an InlineLevelLM
or a LineLM, the new BlockLM is given to its parent, i.e. it will become a
child of the nearest BlockLM ancestor
- an instance of the LM which could not handle the new BlockLM (in the
example, InlineLM son of LineLM) must be created in order to handle inline
siblings of the inner fo:block.

I hope this can help ...

Regards,
Luca




Re: ApacheCon US 2004

2004-11-19 Thread Clay Leeds
On Nov 19, 2004, at 9:53 AM, Glen Mazza wrote:
I'm happy I attended.  The seminars I chose were a mix
of (a) FOP-related or semi-related, (b) development
topics that I thought might help me at work, and then
(c) topics that I don't know much about, but attended
just to get an intro knowledge of the subject.
Glad to hear you were trying to learn something... ;-)
I was happy to be able to meet and talk with Ted Leung
and David Crossley (and, yeah, David and I talked
about you Clay! ;), also, at least got to quickly
introduce myself to Dirk-Willem.
Glen
Yeah... I thought something was up... My ears were burning ;-). At 
least Dirk-Willem can't say he doesn't recognize any of the XML 
Graphics PMC any more... :-p

Thanks for the report!
Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


RE: [Bug 32253] - Marker bugs

2004-11-19 Thread Andreas L. Delmelle
 -Original Message-
 From: Luca Furini [mailto:[EMAIL PROTECTED]


Hi,

 A block inside an inline inside a block
snip /
 creates:
 a) 3 different paragraphs too:
snip /
 b) a single paragraph with all the text:
snip /
 I'd say a), but I'm not sure.

My very first thought was a) too, but then again, I'm still wondering what
the intention is of allowing this sort of block-inline-block nesting in the
first place.
I'm unsure what the difference *should* be between the above and the case
where the inner block is *not* nested inside an fo:inline...
Since it is allowed by the spec: what is the intended effect of having a
block/list-block/table nested inside an inline?

Maybe something like this makes it clearer:
fo:block font-size=40pt
  A
  fo:inline font-size=6pt
fo:block
!-- add a long text here --
/fo:block
  /fo:inline
  B
/fo:block

which is then supposed to be rendered as two very large letters 'A' and 'B'
with, for example, a story in very small letters in between. (Although one
could argue that a similar effect can be achieved by a three column table
where the first and third column contain the two large letters, and the
second column contains the story...)

If this was the intention, then the proposed 'handing off the BlockLM to the
ancestor BlockLM' wouldn't work... :-(


Greetz,

Andreas



DO NOT REPLY [Bug 32327] New: - Basic-link w/ 'mailto:' URL behave improperly

2004-11-19 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32327.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32327

   Summary: Basic-link w/ 'mailto:' URL behave improperly
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


(moved here from fop-user)

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

 I'm putting an email link into my pdf using teh following 
 fop syntax in my xsl... 
 E-mail: fo:basic-link external-destination=mailto:[EMAIL PROTECTED]
  [EMAIL PROTECTED]/fo:basic-link 

 Clicking on the link in the created PDF brings up an email 
 client ok but it also brings up a browser which tries to 
 access the url 'mailto:[EMAIL PROTECTED]'.

I have verified this. Indeed 0.20.5 opens up a browser, and so does HEAD. I 
can't seem to find *any* reference to this in the PDF Specification, but 
apparently iText succeeds in adding 'mailto:' links that perform the correct 
action.

We'll definitely have to have a look at how iText handles these (when we have 
some spare-time)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


RE: [Bug 32253] - Marker bugs

2004-11-19 Thread Andreas L. Delmelle
 -Original Message-
 From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]


Just noticed a slight error...

 Maybe something like this makes it clearer:
 fo:block font-size=40pt
   A
   fo:inline font-size=6pt
 fo:block

The smaller font-size should be added as a property to the inner block
instead of to the inline.



Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Simon Pepping
On Fri, Nov 19, 2004 at 08:14:35PM +0100, Andreas L. Delmelle wrote:
  -Original Message-
 Hi,
 
 My very first thought was a) too, but then again, I'm still wondering what
 the intention is of allowing this sort of block-inline-block nesting in the
 first place.
 I'm unsure what the difference *should* be between the above and the case
 where the inner block is *not* nested inside an fo:inline...

Not much I think. An inline in a block is usually used to specify
different properties for its content.

 Since it is allowed by the spec: what is the intended effect of having a
 block/list-block/table nested inside an inline?
 
 Maybe something like this makes it clearer:
 fo:block font-size=40pt
   A
   fo:inline font-size=6pt
 fo:block
 !-- add a long text here --
 /fo:block
   /fo:inline
   B
 /fo:block
 
 which is then supposed to be rendered as two very large letters 'A' and 'B'
 with, for example, a story in very small letters in between. (Although one
 could argue that a similar effect can be achieved by a three column table
 where the first and third column contain the two large letters, and the
 second column contains the story...)

I do not think that is the correct layout. It should be a large A on a
line, followed by any text with which the inline would start (none in
your example). Then the block would have its own full text width block
area. Then there would be more lines with the ending text of the
inline (none in your example) and a large B.

The layout you describe can be achieved using an inline-container, I
believe.
 
 If this was the intention, then the proposed 'handing off the BlockLM to the
 ancestor BlockLM' wouldn't work... :-(

There may well be several ways in which the user can specify a certain
layout.

Regards, Simon

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



Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Simon Pepping
On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote:
 A block inside another block
 
 fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block
 
 creates 3 different paragraphs:
 - Normal text
 - inner block
 - normal text.
 and each paragraph's layout is unrelated to the other paragraphs' layout 
 (there are 3 LineLM).

The 'normal text' is not indented, which makes it a 'continuation paragraph'.
 
 A block inside an inline inside a block
 
 fo:blockNormal text fo:inline background-color=lightgreeninline text 1
 fo:blockinner block/fo:block inline text 2/fo:inline normal
 text./fo:block
 
 creates:
 a) 3 different paragraphs too:
 - Normal text inline text 1
 - inner block
 - inline text 2 normal text.
 or
 b) a single paragraph with all the text:
 - Normal text inline text 1 inner block inline text 2 normal text.
 ???
 
 I'd say a), but I'm not sure.
 If this were true, there should be 3 different LineLMs.

I would say so too. I think that is what the spec prescribes for
fo:block. The fo:block is positioned w.r.t. the current reference
area, not w.r.t. the containing fo:inline. That makes it very similar
to the first example.

I believe the above is in fact a common layout pattern. It describes a
displayed equation in the middle of a paragraph. The second example
adds some layout characteristics, like specifying a different color,
font size, etc.
 
 This is the LM tree at the moment:
 
  BlockLM1
 |
  LineLM1
 |
-+-
|||
 TextLM  InlineLM  TextLM
 Normal text   |  normal text.
 |
-+-
|||
 TextLM   BlockLM2 TextLM
 inline text 1 | inline text 2
  LineLM2
 |
  TextLM
   inner block
 
 LineLM1 tries to have get elements from all its chidren, and fails.
 
 But, even if it could be given the elements representing inner block, it
 could layout them wrongly, because of the block properties: the inner
 block could have different alignment, borders, margins, indents, 
 
 So, the LM tree could be:
 
 BlockLM1
   --+-
   | ||
LineLM   BlockLM2  LineLM
--+--|   -+-
|   ||   | |
 TextLM InlineLM  LineLM InlineLMTextLM
 Normal text  ||   |normal text.
||   |
 TextLM   TextLM  TextLM
inline text 1   inner block   inline text 2
 
 This modified tree can be easily obtained from the previous one:
 - the new BlockLM is created
 - if the LM which should add it to its children list is an InlineLevelLM
 or a LineLM, the new BlockLM is given to its parent, i.e. it will become a
 child of the nearest BlockLM ancestor
 - an instance of the LM which could not handle the new BlockLM (in the
 example, InlineLM son of LineLM) must be created in order to handle inline
 siblings of the inner fo:block.

The third LineLM is not easy to program. Moreover, it has to know the
requirement that it does not start with an indent.

I think the first hierarchy is preferable and can be made to handle
the situation as follows.

The LineLM needs to be able to deal with paragraphs and blocks.

InlineLM's getNextKnuthElements should signal the end of the paragraph
(same as forced linefeed?) if it encounters a block-area generating
child LM. The next call to it should call the child LM's
getNextBreakPoss method, and return the BPs for the lines in the
block. InlineLM's getNextKnuthElements would return KnuthElements and
BPs. How can these return types be mixed?

LineLM's getNextBreakPoss would collect the returned KnuthElements in
paragraphs, and determine the BPs in it. It would store the BPs
received from its children unmodified.

The inner block would create its own areas, with proper alignment,
borders, margins, indents, etc.

Regards, Simon

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



FOP Web site updated

2004-11-19 Thread Web Maestro Clay
Howdy folks,
I updated the Apache FOP web site. It now uses Apache Forrest 0.6, a 
new skin/theme and (drum roll please...) new FOP logo. Other the 
changes included in this 'release':
- new, improved look  feel ;-)
- new FOP logo (thanks to all submitters  especially Scott Hoffman  
Victor Mote!)
- wholesite.html[3] file (contains entire site in one 639K file!)
- added xmlgraphics.apache.org link in breadcrumb
- added newest Committers to the Team page[4]
  (we could use blurbs from those of you who haven't provided one ;-)
- added mailing list info  other renderers to FOP Resources page[5]
- added Defoe  FOray to FOP Resources page

In addition, PBW's alt.design/ was renamed Defoe  moved to SF.net[6]. 
I'd like to take this opportunity to thank Peter B. West for his many 
past (and hopefully continuing!) contributions the Apache FOP Project. 
The design/alt.design/ directory no longer exists on FOP. I'll get a 
re-direct for that directory.

There are a few problems with the new site that are still being 
resolved:
- wholesite.pdf is broken (d'oh!) but will be fixed (or removed ;-) 
soon!
- many svg/png/pdf files were transformed 'manually' instead of via 
Cocoon
- the Apache XML Graphics Project logo is a work in progress
- I like darker blue borders on http://www.krysalis.org/ site nav

I welcome the recipients of this e-mail to go through the site and make 
comments.  I took a few liberties here and there (e.g., the breadcrumb 
looks funny, but I *think* it'll be OK...). Everything should be 
up-to-date. Hopefully I've gotten the most recent changes to 
documentation in. Now that I've got the web site rendering I hope to 
have more time for Web site updates and other improvements.

[1] Apache FOP Web Site
http://xml.apache.org/fop/?refresh
[2] Apache FOP Logo Contest
http://xml.apache.org/fop/logocontest.html
[3] Apache FOP Whole Site HTML
http://xml.apache.org/fop/wholesite.html
[4] FOP Team page
http://xml.apache.org/fop/team.html
[5] FOP Resources page
http://xml.apache.org/fop/resources.html
[6] Defoe web site (new home of FOP 'Alt.Design' branch)
http://defoe.sourceforge.net/
Have a nice weekend!
Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
There are 10 types of people in the world:
Those who understand binary, and those who don't.