FOP Web site updated

[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  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]> - 
There are 10 types of people in the world:
Those who understand binary, and those who don't.

Adding competing products to FOP Resources page

[Clay Leeds]

I'm contemplating adding the following products to the FOP Resources 
page:
- FOray
- Defoe

...while I'm at it, I might as well add:
- RenderX - XEP
- AntennaHouse - XSL Formatter
If there are no objections, I will add these (and other?) renders to 
the FOP Resources page.

Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

Re: [Bug 32253] - Marker bugs

[Simon Pepping]

On Fri, Nov 19, 2004 at 06:22:35PM +0100, Luca Furini wrote:
> A block inside another block
> 
> Normal text inner block normal text.
> 
> 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
> 
> Normal text inline text 1
> inner block inline text 2 normal
> text.
> 
> 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

Re: [Bug 32253] - Marker bugs

[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:
> 
>   A
>   
> 
> 
> 
>   
>   B
> 
> 
> 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

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>

Just noticed a slight error...

> Maybe something like this makes it clearer:
> 
>   A
>   
> 

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

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

[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://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: mailto:[EMAIL PROTECTED]">
>  [EMAIL PROTECTED] 
>
> 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

[Andreas L. Delmelle]

> -Original Message-
> From: Luca Furini [mailto:[EMAIL PROTECTED]
>

Hi,

> A block inside an inline inside a block

> creates:
> a) 3 different paragraphs too:

> b) a single paragraph with all the text:

> 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:

  A
  



  
  B


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

Re: ApacheCon US 2004

[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. - 
PGP Public Key: 

Re: ApacheCon US 2004

[Glen Mazza]

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.

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

--- Clay Leeds <[EMAIL PROTECTED]> wrote:

> 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. -
> 
> PGP Public Key:
> 
> 
> 

Re: [Bug 32253] - Marker bugs

[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

Normal text inner block normal text.

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

Normal text inline text 1
inner block inline text 2 normal
text.

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

ApacheCon US 2004

[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. - 
PGP Public Key: