Re: Help Refactoring the Website
On 7/31/07, Vincent Hennebert [EMAIL PROTECTED] wrote:
Hi Clay,
Thanks for chiming in!
I've committed my changes, so the site should be re-factored. There is
likely a bunch of content in the '0.94' realm that needs updating so
it's more relevant to the current release. In addition, there may be
some pages, which will need some attention (like
'branches/fop-0_94/build/site/0.94/releaseNotes_0.94.html',
'branches/fop-0_94/build/site/0.94/changes_0.94.html' and
'branches/fop-0_94/build/site/0.94/knownissues_overview.html').
It didn't take too much to re-factor the site... Just had to adjust
the tabs.xml and site.xml documents (and remove the 0.20.5 documents).
I'll need to do a `svn delete` for the 0.20.5/ and 0.93/ directories,
so let me know if I should do that NOW, or we need to wait until we're
more ready for the release.
As I said I already did it, but if you wanna double-check all the
better. Also, one thing that would be great if you could have a look at,
is improving the stylesheet a bit. For example the main content is set
to be displayed at 80% of its size. That should really not be the case
as the setting for the main text's size should be left to the user's
choice (I'm ok with reducing the size of e.g. the menu, however). I'm
not really sure where to change that as the CSS stylesheets seem to
directly come from the Forrest distribution.
I haven't had a chance to work on the font-size yet, but here're a
couple of links to get started on it if I can't get to it in time:
http://forrest.apache.org/docs_0_70/your-project.html#skins
http://forrest.apache.org/docs_0_70/skin-package.html
FWIW, I tried modifying the
'branches/fop-0_94/src/documentation/skinconf.xml' file, but it didn't
work. I added the 'p, td, li' declaration to adjust it and make it
larger. I didn't commit my change.
Here are a few locations for the Forrest skin files if you want to
modify them (although the CSS change may be overwritten if someone
else changes it (hence it'd be better to find a 'skinconf.xml'
solution):
apache-forrest-0.7/main/webapp/skins/pelt/css/profile.css.xslt
fop/trunk/build/site/skin/profile.css
fop/trunk/build/site/skin/profile.css.xslt
However, I think it's somewhat of a 'moot' point, as in the upper
right of the page, there are increase and decrease font-size widget
buttons, and the settings appear to follow you from page to page...
Here's the snippet,
!--
extra-css - here you can define custom css-elements that are
a. overriding the fallback elements or
b. adding the css definition from new elements that you may have
used in your documentation.
--
extra-css
!--Example of b.
To define the css definition of a new element that you may have used
in the class attribute of a p node.
e.g. p class=quote/
--
p, td, li {
font-size: 94%;
}
p.quote {
margin-left: 2em;
padding: .5em;
background-color: #f0f0f0;
font-family: monospace;
}
.yes { background-color: #99FF99; }
.no { background-color: #FF; }
.partial { background-color: #CC; }
.ForrestTable td.basic { text-align: center; }
.ForrestTable td.extended { text-align: center; }
.ForrestTable td.complete { text-align: center; }
.ForrestTable td.na { text-align: center; }
.ForrestTable td.yes{ background-color: #99FF99;
text-align: center; }
.ForrestTable td.no { background-color: #FF;
text-align: center; }
.ForrestTable td.partial{ background-color: #CC;
text-align: center; }
.ForrestTable td.category { /*background-color: #CFDCED;*/
font-size: 1.2em }
/extra-css
Web Maestro Clay
--
Regards,
The Web Maestro
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: Help Refactoring the Website
Hi Clay,
The Web Maestro a écrit :
On 7/31/07, Vincent Hennebert wrote:
I've committed my changes, so the site should be re-factored. There is
likely a bunch of content in the '0.94' realm that needs updating so
it's more relevant to the current release. In addition, there may be
some pages, which will need some attention (like
'branches/fop-0_94/build/site/0.94/releaseNotes_0.94.html',
'branches/fop-0_94/build/site/0.94/changes_0.94.html' and
'branches/fop-0_94/build/site/0.94/knownissues_overview.html').
That sounds great, thanks! I’ll have a closer look on the WE and
complete if necessary.
As I said I already did it, but if you wanna double-check all the
better. Also, one thing that would be great if you could have a look at,
is improving the stylesheet a bit. For example the main content is set
to be displayed at 80% of its size. That should really not be the case
as the setting for the main text's size should be left to the user's
choice (I'm ok with reducing the size of e.g. the menu, however). I'm
not really sure where to change that as the CSS stylesheets seem to
directly come from the Forrest distribution.
I haven't had a chance to work on the font-size yet, but here're a
couple of links to get started on it if I can't get to it in time:
http://forrest.apache.org/docs_0_70/your-project.html#skins
http://forrest.apache.org/docs_0_70/skin-package.html
FWIW, I tried modifying the
'branches/fop-0_94/src/documentation/skinconf.xml' file, but it didn't
work. I added the 'p, td, li' declaration to adjust it and make it
larger. I didn't commit my change.
Thanks for the pointers. By adding the following in skinconf.xml:
#content { font-size: 100% }
I managed to get normal size for the main text. I didn’t commit the
change because I wasn’t sure this was the right place to do that.
Strangely enough when I run Forrest on my local copy I get different
(smaller) font sizes than on the website for all the other elements but
the main text (without the above change). The screen.css style sheets
are exactly the same though. I wonder what might be happening?
Here are a few locations for the Forrest skin files if you want to
modify them (although the CSS change may be overwritten if someone
else changes it (hence it'd be better to find a 'skinconf.xml'
solution):
apache-forrest-0.7/main/webapp/skins/pelt/css/profile.css.xslt
fop/trunk/build/site/skin/profile.css
fop/trunk/build/site/skin/profile.css.xslt
However, I think it's somewhat of a 'moot' point, as in the upper
right of the page, there are increase and decrease font-size widget
buttons, and the settings appear to follow you from page to page...
Still, the user shouldn’t have to do anything to retrieve their favorite
text size. That’s a basic accessibility rule IMHO.
Moreover, I don’t get any font-size widget button, again both on my
local copy and the website!? FWIW I’m using the Trunk of the 0.7 branch.
snip/
Vincent
Re: AFP Output Resolution
Hi Adrian, Adrian Cumiskey a écrit : Hi, Currently the AFPRenderer is fixed to use a calculation against a static final DPI_CONVERSION_FACTOR_240 to produce 240 dpi output. I've looked at the code, and it looks fairly straight forward to introduce an extra configuration setting which would allow the user to modify this calculation so that other desired resolutions can be produced. So I was thinking of introducing a new variable and trying it out. I thought a candidate name for this setting might be something like target-resolution, but of course we have that already as a general setting for the purposes of adjusting resolution output on bitmap renderers. So what do you think would be a suitable name for this new setting? And do you think it would make sense to have target-resolution and source-resolution (also?) available as a renderer specific setting? Well it seems that target-resolution would also be fine for AFP. Actually, by looking at the doc it seems that this parameter actually has 2 different purposes: the resolution of the output when FOP produces bitmap images, and the resolution of images produced by Batik (although I don’t really get that latter). It will perhaps make sense to separate those 2 purposes and make the former renderer-specific. Something like “output-resolution” would make sense to me. “target-resolution” would be kept as a general setting and would only apply to Batik. Does that make sense? Vincent
Re: AFP Output Resolution
Vincent Hennebert wrote: Hi Adrian, snip/ Well it seems that target-resolution would also be fine for AFP. Actually, by looking at the doc it seems that this parameter actually has 2 different purposes: the resolution of the output when FOP produces bitmap images, and the resolution of images produced by Batik (although I don’t really get that latter). It will perhaps make sense to separate those 2 purposes and make the former renderer-specific. Something like “output-resolution” would make sense to me. “target-resolution” would be kept as a general setting and would only apply to Batik. Does that make sense? Everything except the names. I think it makes sense to have one general purpose resolution setting and then renderer specific settings which control renderer specific resolution. In the case of AFP this will affect more than just imgaes, but for other renderers we are just talking about images. output and target have similar semantics in the English language and the distinction between them will not be clear enough for the users. Maybe the general purpose one (which currently only controls batik) should be default-resolution and it could also apply to images for renderers which dont have an explicit renderer-resolution Chris
Improving Keeps and Breaks
Hi all,
Caution, long post ;-)
I’ve been thinking about the handling of keeps and breaks in tables for
a while, and it seems to me that improvements could be done in that
whole area. I’ll use break-before as an example but what I’ll be saying
applies to break-after and keeps as well.
Currently, for every object to which the break-before property applies,
the value of the property is checked at the beginning of the
getNextKnuthElements method and, if it corresponds to a hard-break,
a Knuth penalty with -inf value is produced. This has several
shortcomings:
- this leads to much code duplication;
- if, say, an fo:block has another fo:block as a child and both have
break-before, two penalties will be generated instead of one (although
I’m suddenly not so sure of that, more later)
- this makes it difficult to improve breaks to distinguish columns from
pages, and keeps to take integer values into account.
In fact, we don’t so much care about the penalty element itself as
whether there /should/ be a break between elements or not. I mean, the
LMs which actually care are those which concatenate the elements:
fo:flow, fo:block, fo:block-container, fo:table-cell, etc. And they all
do it the same way:
iterate over the children LMs
for each LM:
if there is a following LM, then:
if the current LM has break-after or the following LM has
break-before, then
generate a Knuth forced break
So the main question is to know whether there is a break before a LM.
And here that’s quite simple, there are only a few shared behaviours:
indeed there is a break-before on an element if:
- the break-before property is set on the element itself or the first of
its children:
fo:block, fo:block-container, fo:list-block
- it is set on the element itself or any of its children:
fo:table-row, fo:list-item
- it is set on the first of its children:
fo:table-caption, fo:table-cell, fo:list-item-body,
fo:list-item-label, fo:wrapper
- special:
- fo:table: on itself or first table-body
- fo:table-body: on the first fo:table-row child if any; otherwise on
any of fo:table-cell children making the first row
- not applicable:
fo:table-column, fo:table-header/footer, fo:float, fo:footnote-body
So there would just be a couple of methods to write, for each behaviour.
We could (for the moment) define a dedicated class with static methods,
which would be called by each LM (some methods are imaginary, but you
get the idea):
public class KeepsAndBreaksHandler {
public static boolean breakBeforeSelfOrFirstChild(LM lm) {
return lm.getProperty(break-before).isForced() ||
lm.getFirstChild().getProperty(break-before).isForced();
}
public static boolean breakBeforeSelfOrAnyChild(LM lm) {
...
}
public static boolean breakBeforeFirstChild(LM lm) {
...
}
...
}
The method mustKeepWithPrevious would become:
- for BlockLM:
return KeepsAndBreaksHandler.breakBeforeSelfOrFirstChild(this)
- for TableCellLM:
return KeepsAndBreaksHandler.breakBeforeFirstChild(this)
etc.
The static method wouldn’t even need to be made synchronized, as the
class is stateless. Later on we could replace this class with
a Singleton object that would be passed to the LMs at their creation,
and we would have some kind of “KeepsAndBreaksHandlerFactory”. But for
now a simple class with static methods would be sufficient.
We could also put in this class the code for producing the penalties
elements:
KnuthElement getElementForBreakBetween(LM firstLM, LM secondLM) {
if (firstLM.hasBreakAfter() || secondLM().hasBreakBefore()) {
return new KnuthPenalty(...);
} else if (firstLM.mustKeepWithNext() ||
secondLM.mustKeepWithPrevious()) {
return new KnuthForbiddenBreak()
}
}
or something like that.
The benefit would be that the whole handling of breaks can be found in
just one place, instead of being spread among all the LMs. This is
easier to correct bugs; this is easier to implement new features (column
vs page break, integer keeps...); this simplifies the
getNextKnuthElements methods of the LMs. And so on...
WDYT?
Vincent
Re: Expected Behaviour of Nested Break-before
Sorry, attached the wrong FO file. Here it is. Vincent ?xml version=1.0 standalone=no? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=page page-height=10cm page-width=15cm margin=1cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page font-family=serif font-size=14pt fo:flow flow-name=xsl-region-body fo:blockBefore the break/fo:block fo:block break-before=page border-before-width.length=2pt border-before-width.conditionality=retain border-before-style=solid border-before-color=red fo:block break-before=page border-before-width.length=2pt border-before-width.conditionality=retain border-before-style=solid border-before-color=blue Text in the inner block. /fo:block /fo:block /fo:flow /fo:page-sequence /fo:root
Expected Behaviour of Nested Break-before
Hi, I’m suddenly all confused about the supposedly expected behaviour of breaks. Please have a look at the attached FO file and its PDF result. We get 2 pages. The break-before on the outer block and the inner block are “merged” into just one... Why? Section 4.8, “Keeps and Breaks” of XSL-FO 1.1 states that “A break-before condition is satisfied if the first area generated and returned by the formatting object is leading within a context-area.” I could then expect that the outer block generates an empty area on page 2, with a red border-before, plus another area on page 3 (also with a red border due to the “retain”) containing the area generated by the inner block. I mimicked that in the break-before-alt.pdf file. I don’t think anything in the spec contradicts this interpretation. I’m not even sure whether the current behaviour is more desirable from a user-friendliness point of vue or not. WDYT? Vincent ?xml version=1.0 standalone=no? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=page page-height=29.7cm page-width=21cm margin-top=2cm margin-bottom=2cm margin-left=3cm margin-right=3cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page font-family=serif font-size=14pt fo:flow flow-name=xsl-region-body fo:blockSome text./fo:block fo:block break-after=page/ /fo:flow /fo:page-sequence /fo:root break-before.pdf Description: Adobe PDF document break-before-alt.pdf Description: Adobe PDF document
Re: AFP Output Resolution
Vincent Hennebert wrote: Hi Chris, Hmmm, I’m perhaps making a confusion here. I thought target-resolution did also apply to the whole images generated by the renderer; i.e., for the TIFF renderer, the resolution of the image representing the whole document, and not only images inside it. Isn’t that the case? Then, why wouldn’t target-resolution also apply to images in PDF output? Good point. I overlooked the Tiff and PNG Renderers in my reply. Target aka default resolution would apply to images in PDF as well as the resolution of the generated Tiff, PNG etc. Perhaps I should ask the question on fop-user, I’m sure I will find there nice developers who will enlighten me... output and target have similar semantics in the English language and the distinction between them will not be clear enough for the users. Maybe the general purpose one (which currently only controls batik) should be default-resolution and it could also apply to images for renderers which dont have an explicit renderer-resolution renderer-resolution sounds fine to me. Great. I think it is a lot clearer than output-resolution Chris
Re: Help Refactoring the Website
Hi Vincent,
On 8/2/07, Vincent Hennebert [EMAIL PROTECTED] wrote:
The Web Maestro a écrit :
On 7/31/07, Vincent Hennebert wrote:
As I said I already did it, but if you wanna double-check all the
better. Also, one thing that would be great if you could have a look at,
is improving the stylesheet a bit. For example the main content is set
to be displayed at 80% of its size. That should really not be the case
as the setting for the main text's size should be left to the user's
choice (I'm ok with reducing the size of e.g. the menu, however). I'm
not really sure where to change that as the CSS stylesheets seem to
directly come from the Forrest distribution.
I haven't had a chance to work on the font-size yet, but here're a
couple of links to get started on it if I can't get to it in time:
http://forrest.apache.org/docs_0_70/your-project.html#skins
http://forrest.apache.org/docs_0_70/skin-package.html
FWIW, I tried modifying the
'branches/fop-0_94/src/documentation/skinconf.xml' file, but it didn't
work. I added the 'p, td, li' declaration to adjust it and make it
larger. I didn't commit my change.
Thanks for the pointers. By adding the following in skinconf.xml:
#content { font-size: 100% }
I managed to get normal size for the main text. I didn't commit the
change because I wasn't sure this was the right place to do that.
That's perfect. Go ahead and commit...
Strangely enough when I run Forrest on my local copy I get different
(smaller) font sizes than on the website for all the other elements but
the main text (without the above change). The screen.css style sheets
are exactly the same though. I wonder what might be happening?
Can you upload the `forrest` output to your web space, so we can take
a look? Here's the result of mine from last night (without the
#content changes):
http://people.apache.org/~clay/fop-0.94/
Here are a few locations for the Forrest skin files if you want to
modify them (although the CSS change may be overwritten if someone
else changes it (hence it'd be better to find a 'skinconf.xml'
solution):
apache-forrest-0.7/main/webapp/skins/pelt/css/profile.css.xslt
fop/trunk/build/site/skin/profile.css
fop/trunk/build/site/skin/profile.css.xslt
However, I think it's somewhat of a 'moot' point, as in the upper
right of the page, there are increase and decrease font-size widget
buttons, and the settings appear to follow you from page to page...
Still, the user shouldn't have to do anything to retrieve their favorite
text size. That's a basic accessibility rule IMHO.
Moreover, I don't get any font-size widget button, again both on my
local copy and the website!? FWIW I'm using the Trunk of the 0.7 branch.
I wonder if it has to do with your browser setup (what are you
using--browser/version, OS/version w service packs, build etc.)? Have
you tried on another machine? Maybe Forrest needs to have a support
ticket put in about the font resize buttons (and if you prefer the
font-size as well).
snip/
Vincent
--
Regards,
The Web Maestro
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: Help Refactoring the Website
Hi Clay,
The Web Maestro a écrit :
Hi Vincent,
On 8/2/07, Vincent Hennebert wrote:
snip/
Thanks for the pointers. By adding the following in skinconf.xml:
#content { font-size: 100% }
I managed to get normal size for the main text. I didn't commit the
change because I wasn't sure this was the right place to do that.
That's perfect. Go ahead and commit...
Ok, I’ll do.
Strangely enough when I run Forrest on my local copy I get different
(smaller) font sizes than on the website for all the other elements but
the main text (without the above change). The screen.css style sheets
are exactly the same though. I wonder what might be happening?
Can you upload the `forrest` output to your web space, so we can take
a look? Here's the result of mine from last night (without the
#content changes):
http://people.apache.org/~clay/fop-0.94/
Here it is:
http://people.apache.org/~vhennebert/fop-0.94/
snip/
I wonder if it has to do with your browser setup (what are you
using--browser/version, OS/version w service packs, build etc.)? Have
you tried on another machine? Maybe Forrest needs to have a support
ticket put in about the font resize buttons (and if you prefer the
font-size as well).
Firefox 2.0.0.5
Ubuntu Feisty
Revision 556027 of Forrest 0.7 but no CSS file got modified when
I updated my copy (only Java code).
I think I’m becoming crazy. On your version the main text is smaller
than on mine (without applying the CSS change), which now has normal
size. For all other text objects (menu, etc.), sizes are the same.
Trying with Konqueror the main text is larger on my version, but also
the tab titles (Home, Version 0.93, etc.).
I have no font-size button on any version, with any browser. Note that
I have them on the XML Graphics site.
!?!??
Thanks for looking into this,
Vincent
Re: Help Refactoring the Website
On 8/2/07, Vincent Hennebert [EMAIL PROTECTED] wrote: Strangely enough when I run Forrest on my local copy I get different (smaller) font sizes than on the website for all the other elements but the main text (without the above change). The screen.css style sheets are exactly the same though. I wonder what might be happening? Can you upload the `forrest` output to your web space, so we can take a look? Here's the result of mine from last night (without the #content changes): http://people.apache.org/~clay/fop-0.94/ Here it is: http://people.apache.org/~vhennebert/fop-0.94/ The content appears to be *exactly* the same size, but the font-size for the tabs appears to be smaller in our versions. snip/ I wonder if it has to do with your browser setup (what are you using--browser/version, OS/version w service packs, build etc.)? Have you tried on another machine? Maybe Forrest needs to have a support ticket put in about the font resize buttons (and if you prefer the font-size as well). Firefox 2.0.0.5 Ubuntu Feisty Revision 556027 of Forrest 0.7 but no CSS file got modified when I updated my copy (only Java code). I think I'm becoming crazy. On your version the main text is smaller than on mine (without applying the CSS change), which now has normal size. For all other text objects (menu, etc.), sizes are the same. If I were feeling 'feisty' I might say something pithy, like 'You probably are going crazy...' but I'm not so I'll tell you that the reason our sites didn't have the font-size adjust buttons was because they weren't enabled in 'src/documentation/skinconf.xml'. I just enabled it, as well as: - compliance links (shows HTML CSS compliance badges) - external-link-image (indicates off-site links with mini-image icon) - and XML file availability (enables re-purposing of content via XML) Trying with Konqueror the main text is larger on my version, but also the tab titles (Home, Version 0.93, etc.). I have no font-size button on any version, with any browser. Note that I have them on the XML Graphics site. Mentioning that it was on the XML Graphics site gave me the clue it was a preference setting. !?!?? Thanks for looking into this, Vincent Glad I could help... It's been a while since I've delved into Forrest. In fact, they just released Forrest 0.8, so someone may want to look into identifying if there's a compelling reason to 'upgrade'. ;-) -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
