Re: More style issues
+1 to all three points. But I'll never define a variable called
blockProgressionDimension! That's always going to be bpd for me, but
then ipd and bpd are so omnipresent so it shouldn't be a problem.
Exceptions prove the rule, don't they? :-)
On 09.09.2005 01:55:06 J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
Regards
J.Pietschmann
Jeremias Maerki
Re: More style issues
Jeremias Maerki wrote: +1 to all three points. But I'll never define a variable called blockProgressionDimension! That's always going to be bpd for me, but then ipd and bpd are so omnipresent so it shouldn't be a problem. blockProgressionDimension or blockProgressionDirection? Exceptions prove the rule, don't they? :-) They certainly throw it into contrast. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Space-resolution doesn't work
I think we need to revisit the whole space-resolution story. The current code is fine for only the simplest of cases. If you look at the 4.3.1 Space-resolution Rules in the spec the example given there shows quite clearly IMO that we probably can't just rely on the right combination of Knuth elements to resolved the spaces. Especially rule 3 is quite nasty. I'll start from scratch to come up with a better strategy of implementing these rules. I'll probably start by documenting a few cases in the Wiki and try to develop the right element list for them. After that I'll try to find out who exactly to implement everything. Help is welcome. Jeremias Maerki
Re: Space-resolution doesn't work
Jeremias Maerki wrote:
I'll start from scratch to come up with a better strategy of
implementing these rules. I'll probably start by documenting a few cases
in the Wiki and try to develop the right element list for them. After
that I'll try to find out who exactly to implement everything. Help is
welcome.
I think spaces and keeps are quite similar and very connected: in both
cases, the constraints can invole formatting objects that are not at the
same depth in the tree.
So, my idea for handling space resolution is tho have a LM ask its
children about their spaces, and create the necessary elements (while at
the moment each LM creates elements for its own spaces).
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
where:
- the method createElementsForSpace() can have a single space parameter
(returning a sequence that has no feasible breaks [1]) or three
different spaces parameters (returing a sequence with a feasible break
[2]);
- resolve takes two spaces and two booleans, signalling if the space will
be at the beginning / end of a page (as this affects the resolved space)
- getSpaceAfter() would be something like
return resolve(this.spaceAfter, lastChild.getSpaceAfter(), false, false);
vice-versa, getSpaceBefore would be
return resolve(this.spaceBefore, firstChild.getSpaceBefore(), false, false);
(a similar mechanism could be used for keeps)
but I'm not sure that adding two spaces at a time would always give the
same result.
Otherwise, we could follow the implementation of keeps, using the
LayoutContext to keep track of the spaces met and not yet converted into
elements.
Regards
Luca
[1] this would be a simple glue element, preceded by a penalty with value
= inf
[2] maybe a sequence glue - penalty - glue - box - PENALTY - glue,
with
glue #1 is the resolved space after block 1 if a break occurs
glue #3 is the resolved space before block 2 if a break occurs
penalty is a feasible break
PENALTY forbids a break
glue #3 is the difference between glue #1 + glue #3 and the resolved
space if there is no break
RE: Relative font weights and font selection
Victor Mote wrote (on Monday): The following methods have now been added to org.axsl.font.Font: public byte nextBolderWeight() ; public byte nextLighterWeight() ; public Font nextBolderFont() ; public Font nextLighterFont() ; public int unavailableChar(String string, int beginIndex) ; public int unavailableChar(char[] chars, int beginIndex) ; public int[] unavailableChars(String string, int beginIndex) ; public int[] unavailableChars(char[] chars, int beginIndex) ; and a char has been added to the signature of the method org.axsl.font.FontServer.selectFont. Stub implementations have been created in FOray, but the added functionality is, in general, not actually in place yet. I'll get to that as I am able, but at least those working with the interface can move forward when they are ready. FOrayFont now has fully functional implementations of all of these methods, and its font selection logic has been upgraded to use them. With the *possible* exception of font-selection-strategy (I will start a separate thread on this issue shortly), I think that FOray's font selection is now fully conformant. FOrayFOTree has also been upgraded to use the font-selection properly, and to compute the relative font weights using the new aXSL font methods. If it helps, Vincent and Manuel can use this as a template when implementing in FOP. The only real trick in FOray was getting the first chunk of text that should be considered. If that task is difficult in FOP, and you wish to defer it, you can probably safely do so by sending the space character 0x20 to the FontServer.selectFontXSL method. Most, if not all, fonts will be able to encode that character. There are some user issues that result from the new conformity, WRT simulating small-caps. The small-caps simulation logic that FOray inherited from FOP had the following features: 1. Used a hard-coded 80% figure. 2. The decision to use small-caps at all, always simulated, was made entirely outside of the font system. 3. Actual simulation of small-caps took place outside of the font system. In order to build a conformant font selection, items 1 and 2 above have been pulled into the font system. The aXSL font configuration DTD now includes for the font-description element an attribute called simulate-small-caps, which takes a percentage. Existence of the simulate-small-caps attribute also allows the font-description to be selected for either font-variant=normal or font-variant=small-caps requests. User must now provide a simulate-small-caps attribute for small-caps simulation to even be considered in the font-selection process. The font-selection logic should pick a true small-caps variant before picking one that merely simulates small-caps. Also the following method has been added to the Font interface to expose the new information provided in font configuration: public int smallCapsSize(int fontSize); This method returns the fontSize that should be used for intrinsically lowercase characters. Remember that the font system doesn't know when small-caps simulation is actually being used (item 3 above). It only knows whether it can be used or not, and, if so, the scaling factor that should be applied. BTW, the DTD now also includes the following font-description attributes: simulate-oblique CDATA #IMPLIED simulate-backslant CDATA #IMPLIED simulate-ultra-condensed CDATA #IMPLIED simulate-extra-condensed CDATA #IMPLIED simulate-condensed CDATA #IMPLIED simulate-semi-condensed CDATA #IMPLIED simulate-semi-expanded CDATA #IMPLIED simulate-expanded CDATA #IMPLIED simulate-extra-expanded CDATA #IMPLIED simulate-ultra-expanded CDATA #IMPLIED These are intended for aXSL implementation that wish to simulate font-style and font-stretch values. I have documented these pretty heavily in the DTD itself for those who want more detail. Victor Mote
font-selection-strategy
FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the character-by-character option. My current reading of the spec is that the auto option is merely an opportunity, a hook if you will, for an implementation to do something fancier than character-by-character. This whole attribute is actually an extension to CSS, which only does character-by-character. The definition of auto is The selection criterion given by the contextual characters is used in an implementation defined manner. That seems to cover almost anything doesn't it? Including character-by-character. The Note under auto seems to confirm this. Nevertheless, the example given in the Note provides some ideas for other algorithms, and seems to suggest that there is room for more than one. So, the general framework would seem to include the definition of one or more such algorithms, naming each one, and then providing that name through some global-ish mechanism like a font-configuration file or other configuration option. The font system can then implement the algorithm, perhaps with the help of call-back methods to provide, for example, the various pieces of contextual text. Now, I suggest that the creation and definition of such algorithms should be driven by the user base. IOW, if a user wishes to suggest an algorithm for font-selection that provides something useful to them, it should be considered. I say this partly because I don't seem to have a need for any such thing. My general approach is going to be to provide a list of exactly one font-family and then (by perusing the log!!) make sure that font-family actually got used. If it did not, I'm going to consider my stylesheet to be deficient as opposed to the font selection algorithm. In other words, I am going to implement my own manual algorithm. The other wrinkle that the standard seems to present is qualitative judgments like better quality fonts and match each other badly stylistically. I know of no way to get this information other than asking the user for it. So it is likely that some algorithms will require additional information in font-configuration. This post does not require any response from anyone. I realize you are trying to get a release out the door. I just wanted to document my thoughts on the matter for you before they escaped. Victor Mote
Tables, Columns... : FOTree or Layout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, In my attempt to facilitate an implementation of the collapsing border model on tables by moving the lion's share of the logic from layoutmgr.table over to the fo.flow package, I stumbled upon some other parts that are currently dealt with at layout stage while I feel they don't really belong there. To put it generally: there are questions about a table's structure that can be answered by looking *solely* at the tree structure itself (i.e. no details about the how, when or even if of layout are required). The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. Another related issue then, is that of storing the columns as a List. Currently, in layoutmgr.table.ColumnSetup, an error message is logged when there is a gap (i.e. non-occupied column-numbers). According to the Rec, this is no error, since there is no need for column-numbers to be monotonically increasing from one formatting object to the next (see: 7.26.8 column-number) This is probably why no exception is thrown (?) I take this to mean that an author can decide to number the first column as 3, and specify a number of 7 for the next. To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. The larger the gaps and the more spanning columns, the more unnecessary nulls to add. So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDIh2byHTbFO9b8aARAmxiAJwOmZ20noM4AASe1yX+NEEJQFCT5wCdGdK0 l5ruWzp04zIKuFakiBQMr6I= =dpCF -END PGP SIGNATURE-
