Re: Getting more and more private inquiries about FOP's state
On 05.04.2005 21:59:48 Renaud Richardet wrote: Jeremias Maerki wrote: Today alone, I've had to reply to two mails sent to me directly. What did the people wanted to know? With FOP's State, do you mean the date of the next release? - Is the project dead? - Give me release dates or a link to a project/release plan so people can plan their own projects. - What's JFOR's status? Is the integration into FOP complete? Stuff like that... Does anyone have an idea how we can improve communication on FOP's state and direction? Start a blog about FOP hacking and put a prominent link to it on the FOP home page. Somethinkg like The burning edge for FireFox. What I like about the Blog, is that it's easy to update. But we could do the same in a wiki page. Please have a look at my proposition [1]. I think it's very lightweight to maintain, and it gives the impression to visitors (and to developpers) that FOP is under active developpment. The Cocoon wiki even lists these kind of news on their FrontPage [2]. I like the idea. I like it, too! I also updated the documentation a tiny bit [3]: * updated FAQ with 2 new questions * updated dev/index * could we put something on relnotes.html? When you read it, it gives you the feeling that the project is dead (which doesn't reflect the reality). Thanks a lot, Renaud. That's fantastic. I'll have a look at it right now. BTW, how's your Java2D stuff? Regards, Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FOPNews [2] http://wiki.apache.org/cocoon/FrontPage [3] http://issues.apache.org/bugzilla/show_bug.cgi?id=34316 Jeremias Maerki
DO NOT REPLY [Bug 34316] - [Patch] for website, reflecting the status of FOP
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=34316. 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=34316 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-04-06 09:10 --- Applied with little modifications. Thanks a lot! -- 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: two more class renamings
Oops, make that three differences: their content models (child FO's that the spec says they can have) are slightly different. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: --- The Web Maestro [EMAIL PROTECTED] wrote: or something. That way, it's all in one (since it can apparently be repurposed anyway, with fo:flow being stuck into fo:static-content, and Be careful here: fo:flow being placed into a side region, or fo:static-content being placed into the body region (or main reference area). We really need to start divorcing the fo:static-content/fo:flow terms from where they are usually placed on the paper. The two differences between fo:flow and fo:static-content are: 1. fo:static-content is to be repeated from its start on every page, and truncated if it doesn't fit. 2. fo:flow is not repeated, but additional pages created until it its contents are finished. Regions of that these FO's are placed on are really not part of the equation. Glen
RE: two more class renamings
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 9:59 AM 1. fo:static-content is to be repeated from its start on every page, and truncated if it doesn't fit. You state this very simply and clearly here, but it has always struck me curiously. There appears to be a gaping hole in the specification that does not satisfy the need to have content repeat on every page that does *not* truncate when it does not fit. The extent attribute on all regions that surround the page explicitly defines the size, but I've found it interesting that there was not an option to have an auto setting that would resize the region to fit the content. I first thought that this was a 1.0 thing and that in the next version it would be addressed, but this comment you made that explicitly says the desired behavior of static-content is to truncate when it does not fit and that there are no plans to address it. Do you or anyone else on the developer list know of a compelling reason why this is the case? CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. --
RE: two more class renamings
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Sorry to be such a nitpick, but the 1.0 Rec. states literally: An fo:marker is only permitted as the descendant of an fo:flow. and An fo:retrieve-marker is only permitted as the descendant of an fo:static-content. Thanks for the correction--I had checked just the content model of fo:flow, which indicated fo:retrieve-marker would be allowed. It would be nice if those two statements above were duplicated in the parent's CM descriptions--that's where people normally go to see which child FO's are allowed/disallowed. Perhaps I'll make a request to the xsl editors ML sometime. Glen
leader dot ends don't line up
Hi
I am new to this mailing list (also fop user mailing list too),
although I have been using FOP for about a year.
Anyway, I had a small problem with dots leader, they did not line up
at the end, and the gap is less than one dot. But still my client
didn't like it. (I am using FOP-0.20.5 July 15, 2003 build version)
My stylesheet like this
xsl:template match=tableContents
fo:table table-layout=fixed
fo:table-column column-width=90mm/
fo:table-column column-width=10mm/
fo:table-body
fo:table-row
fo:table-cell
fo:block text-align-last=justify
font-size=11.08pt font-family=Bell Gothic Bold
font-weight=bold
Result 1
fo:leader leader-pattern=dots/
/fo:block
/fo:table-cell
fo:table-cell text-align=right margin-right=-1.3mm
fo:block font-size=11.08pt
font-family=Bell Gothic Bold font-weight=bold
fo:page-number-citation ref-id=R1 /
/fo:block
/fo:table-cell
/fo:table-row
xsl:for-each select=AppendixPageContent
xsl:call-template name=addtionalTableContents/
/xsl:for-each
more contents
/fo:table-body
/fo:table
/xsl:template
xsl:template name=addtionalTableContents
fo:table-row
fo:table-cell
fo:block text-align-last=justify font-size=11.08pt
font-family=Bell Gothic Bold font-weight=bold
#160;#160;#160;#160;#160;xsl:value-of
select=value/#160;fo:leader leader-pattern=dots/
/fo:block
/fo:table-cell
fo:table-cell
fo:block text-align=end font-size=11.08pt
font-family=Bell Gothic Bold font-weight=bold
xsl:value-of select=page//fo:block
/fo:table-cell
/fo:table-row
/xsl:template
(margin-right for page-number-citation cell is to adjust with the other
page numbers from addtionalTableContents)
Some dots leader didn't reach to the table cell end, i.e.
they don't line up. If dots change to rule, it is fine.
So I look at the source code src.org.apache.fop.layout.LineArea.jave
that generate leaders.
From line 205, it is generating leader.
+++ Original Source +++
int factor = (int)Math.floor(leaderLengthOptimum / dotWidth);
char[] leaderChars = new char[factor];
for (int i = 0; i factor; i++) {
leaderChars[i] = dot;
}
String leaderWord = new String(leaderChars);
int leaderWordWidth = fontState.getWordWidth(leaderWord);
WordArea leaderPatternArea =
new WordArea(fontState, red, green, blue,
leaderWord,leaderWordWidth);
leaderPatternArea.setYOffset(placementOffset);
children.add(idx, leaderPatternArea);
int spaceAfterLeader = leaderLengthOptimum
- leaderWordWidth;
if (spaceAfterLeader!=0) {
children.add(idx+1, new InlineSpace(spaceAfterLeader,false));
++ Original Source End +
factor is the number how many dots can be fit in the space.
and added it to children and add left space as space
So, the dot line end did not line up.
First I tried to replace the order InlineSpace and leaderPatterArea
but it didn't work (nothing changed)
So, I generated additional WordArea using 1pt space and added before dot
leader. The source is like this.
+++ Changing Source +++
if (spaceAfterLeader 0) {
// create WordArea with 1pt space to fill space before leader
FontState newFontState = null;
try{
newFontState = new FontState(fontState.getFontInfo(),
fontState.getFontFamily(),
fontState.getFontStyle(),
fontState.getFontWeight(), 1000,
fontState.getFontVariant());
}
catch(FOPException e)
{ }
int subSpaceWidth = newFontState.getCharWidth(space);
int spaceFactor = (int)Math.floor((double)spaceAfterLeader
/ (double)subSpaceWidth);
char[] spaceLeaderChars = new char[spaceFactor];
for (int i = 0; i spaceFactor; i++) {
spaceLeaderChars[i] = space;
}
String spaceLeaderWord = new String(spaceLeaderChars);
WordArea spaceLeaderPatternArea =
new WordArea(newFontState, red, green, blue,
spaceLeaderWord,subSpaceWidth * spaceFactor);
leaderPatternArea.setYOffset(placementOffset);
spaceLeaderPatternArea.setYOffset(placementOffset);
children.add(idx, spaceLeaderPatternArea);
idx++;
children.add(idx, leaderPatternArea);
idx++;
++ Changing Source End +
It solved the problem.
But
