Re: markers in redesign
J.Pietschmann wrote at 3 Mar 2003 21:58:55 +0100: This still leaves the question: Does a block with a break-before=page or a break-after=page span two pages, or will it always be the first/last area on the page its content is rendered on? One page (assuming it fits within one page). 7.19.1, break-after Specifies that the first normal area generated by formatting the next formatting object, if any, shall be the first one placed in a particular context (e.g., page-area, column-area). 7.19.2, break-before Specifies that the first area generated by this formatting object shall be the first one placed in a particular context (e.g., page-area, column-area). Examples fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? I'd think m2. So do I. fo:block id=A break-after=page fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? Probably m1, but where in the spec can I find backing for this opinion? I think m2, since B follows A in a pre-order traversal order. 7.23.3. retrieve-position last-ending-within-page Specifies a preference for retrieving the children of an fo:marker attached to an area that is within the containing page whose is-last trait is set to true and that follows in the area tree any other similarly constrained area that is attached to an identically named fo:marker, using pre-order traversal order. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: markers in redesign
Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: February 24, 2003 6:53 AM To: [EMAIL PROTECTED] Subject: Re: markers in redesign [ SNIP ] It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. Yes, that's my interpretation. Precisely so. It is tempting to confuse hierarchy for tree. But the language of the spec in regard of markers defines a different hierarchy, one which happens to map closely to the area tree, but is highly filtered. It's not just areas. fo:wrapper 'does not generate any areas', but also 'may always have a sequence of zero or more fo:markers as its initial children.' ... The thing that bugs me is, when there is no qualifying area in the containing page (Note to spec editors: try saying currently-formatted page), after filtering, then it becomes anarchy. It seems like user I wasn't there when the spec was written, but it seems to me that 'currently-formatted page' presupposes making pages on the fly and doesn't quite describe pages that are unbounded in one or both directions (i.e. where there is only ever one page) and also doesn't describe the possible processing model of making all the pages from the fo:flow and then going back and fixing up the static content. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: [xsl] Sun xmlroff XSL Formatter as SourceForge Project]
Oleg Tkachenko wrote at 20 Feb 2003 10:42:11 +0200: Hello there! So, xmlroff is available at SourceForge now. Yes. And Robin Cover did such a good summary page on the announcement that it's a hard act to follow. I expect this to be my last post to fop-dev about xmlroff. If you are interested in xmlroff, see the SourceForge sites. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 Original Message Subject: [xsl] Sun xmlroff XSL Formatter as SourceForge Project Date: Wed, 19 Feb 2003 14:44:42 -0600 (CST) From: Robin Cover [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] See: http://xml.coverpages.org/ni2003-02-19-a.html http://sourceforge.net/projects/xmlroff/ http://xmlroff.sourceforge.net/index.html Apologies if this is a duplicate reference. Robin - Robin Cover XML Cover Pages WWW: http://xml.coverpages.org Newsletter: http://xml.coverpages.org/newsletter.html XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
Patrick Dean Rusk wrote at 17 Dec 2002 17:40:11 -0500: Perhaps Tony knows better, but I have a potentially plausible explanation for Sun being secretive about their project: it may not initially have been intended for eventual open source development. In other words, it could be a failed internal project to create a commercial product. No. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
Arved Sandstrom wrote at 14 Dec 2002 15:05:05 -0400: No bitterness at all, actually, Peter. It takes a bit of wind out of my sails, sure, since xmlroff is so similar to the project that Eric Bischoff and myself were working on. Tony has certainly been aware of that for quite a long time - I don't understand why the secrecy, myself, seeing as how we are now looking at an OSS donation anyway. Sun policy, not personal policy. I assure you that there are many steps, and many signatures, required when a large corporation makes an open source donation. Purely because it is a large corporation making the donation and not an individual contributor, there is a lot of due diligence to be done. If a project can't pass all the criteria, it won't be made public. Since a project intended for open souce may not make it to open source, it is perhaps better to say nothing until the due diligence is completed (or, in this case, very nearly completed). The alternative -- announcing an intention to make a public source donation -- risks the project not passing the criteria and risks later accusations of vapourware or accusations of lack of commitment to open source when the project can't be made public. That's why I couldn't say anything about the formatter in the lead up to XML 2002: any of a number of people -- not just engineers and engineering managers -- could have vetoed the donation for any of a number of reasons, and I would have just had to withdraw from the conference without another word being said. I'd be bitter if I were so arrogant as to think of myself as being upstaged. :-) That's not the case. I am quite familiar with the spec, and there are now a number of competing efforts. None of which are quite accurate. So there is room for more competition. Alternatively, I may talk to Tony and Eric and see if we can assist. Part of why it is written in C is so it doesn't compete with FOP for developers. Arved took the wind out of my sails for a while when he announced his SourceForge project, so wind taking runs both ways. I would be pleased if Arved and/or Eric would consider assisting with the project. Frankly, I would be pleased if *anybody* assisted with the project, but Arved and Eric would be a bonus. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Sun XSL Formatter
Peter did ask... The Sun xmlroff XSL formatter is written in C, and it uses libxml2 and libxslt plus the GLib, GObject, and Pango libraries that underlie GTK+ and GNOME (although it does not require either GTK+ or GNOME). The formatter currently produces PDF output only. xmlroff is a command line program, but the bulk of the XSL formatting is implemented as a libfo library that can be linked to any program that requires XSL formatting capability. It will be available under a BSD license. It is being developed on both Solaris and Linux. The formatter is awaiting final approval before the code can be made public source. An announcement will be made on xsl-list, www-xsl-fo, and XSL-FO@YahooGroups once the code is available. Regards, Tony Graham XML Technology Center Sun Microsystems Ireland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: character
Peter B. West wrote at 30 Sep 2002 13:28:18 +1000: Tony Graham wrote: [EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300: ... That means -, #12235 , etc are characters, while '1' is not. #12235; is a character reference. '#12235' is how you talk about a character's code point, although the hexadecimal representation is usually preferable. In XSL terms, '1' is a one-character string literal, but while you could claim that it is one character, there's no XSL conversion from a string to a character, so fo:character character='1'/ should fail. Tony, I don't think this gets us out of difficulty. A casual inspection Forgive me, but I wasn't trying to get anybody out of any difficulty, I was just trying to keep the terminology accurate. ... So how do I represent a character? To me, the cleanest, least ambiguous way is to represent a character attribute assignment value with 'character' - a string literal of length 1. Except that you know that that's not specified among the allowed conversions. The interesting thing is that 'character' doesn't appear in the productions in Section 5.9, Expressions, of the XSL Recommendation. Now there's a question for [EMAIL PROTECTED]! I think that you represent a character as a single character, e.g., character=c, or as a numeric character reference, e.g., character=#xA;. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: character
Arved Sandstrom wrote at 26 Sep 2002 19:50:01 -0300: Tony Graham says that character should be a Unicode character, or Char. As in the actual real, encoded thing. Empirical evidence suggests that is the general understanding: grepping the XSL CR test suite shows everybody, FOP included, using literal characters. Problem being, one property with a character datatype is defined in XSLT, which actually says that it's a Char. hyphenation-separator merely says that it's a specification of a Unicode character. I guess that could be interpreted the same way. But character for the character property says _code point_. And that is an integer value. Section 5.11, Property Datatypes, trumps the individual property definitions, since Section 5.11 defines the syntax for specifying the datatypes usable in property values. It says A single Unicode character. Now, the interesting if so far theoretical case is what do you do if you want a hyphenation-separator character that you can only represent in Unicode as the combination of a base character and one or more combining marks? What if your precomposed character gets normalised to a base character and a combining mark before the XSL processor sees it? So IMO the spec is currently very vague on this. Then write to [EMAIL PROTECTED] asking for a clarification. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: character
Peter B. West wrote at 28 Sep 2002 00:39:34 +1000: ... Tony Graham wrote: ... Section 5.11, Property Datatypes, trumps the individual property definitions, since Section 5.11 defines the syntax for specifying the datatypes usable in property values. It says A single Unicode character. Ok, so it's a character. How, then, is it represented? Is it also a string (of length one), or is it just a literal (length 1), or just an NCName (length 1), or is it something else? What does it look like, and how is the parser going to handle it? A character is a character, and you should go to XML 1.0 for the definition of a character. Also, parser is ambiguous in this context as well as having no XML or XSL meaning. XML defines an XML processor, which is often called a parser for historical reasons, and the XSL Recommendation uses parse without designating a thing called a parser. ... So IMO the spec is currently very vague on this. Then write to [EMAIL PROTECTED] asking for a clarification. Nice dry wit you have Tony. That was a serious suggestion. You do get an answer eventually, even if you don't like the answer. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: character
[EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300: Out of the XML recomendation,section 2.2: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO10646]. Legal characters are tab, carriage return, line feed, and the legal graphic characters of Unicode and ISO/IEC 10646. XML 1.0 Second Edition removed graphic (which I always found confusing but which is good ISO-speak). or, more clearly: Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] /* any Unicode character, excluding the surrogate blocks, FFFE, and . */ That means -, #12235 , etc are characters, while '1' is not. #12235; is a character reference. '#12235' is how you talk about a character's code point, although the hexadecimal representation is usually preferable. In XSL terms, '1' is a one-character string literal, but while you could claim that it is one character, there's no XSL conversion from a string to a character, so fo:character character='1'/ should fail. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Karen Lease wrote at 20 Aug 2002 23:07:46 +0200: That would be good. I haven't looked at it for a month or so, but I had (as usual) some questions about various statements in the XSL-FO spec concerning the interpretation of the various properties. Perhaps we could go over those issues at some point. ... Arved Sandstrom wrote: -Original Message- From: Karen Lease [mailto:[EMAIL PROTECTED]] ... With regard to the line-height calculations, is anybody in the group interested in getting into the gory details of the baseline stuff for different scripts? I spent some time poring over the spec and trying to get a handle on this, but maybe it's too much detail for now. On the other hand, I'd really like to make sure that this version of FOP handles that stuff correctly as well as being able to do the various kinds of line-stacking strategies defined by the XSL-FO spec. I am definitely interested. I have put some thought into these things already. Granted, when I implement it'll be a different codebase but I am happy to work out the details on this list. You may be interested in Steve Zilles's statement in the abstract [1] for his talk at next month's Unicode Conference where he says: The extended CSS/XSL model is based on the Open Type font model. This model posits a set of alignment baselines for different scripts, e.g., alphabetic, ideographic and hanging scripts. This allows characters in a given script, but presented in different font sizes, to be aligned on the baseline natural to that script. I just looked in the XSL Recommendation, and Section 7.8.1 notes: XSL uses an abstract model of a font. This model is described in this section and is based on current font technology as exemplified by the OpenType specification [OpenType]. Maybe you also need to look at the OpenType spec. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 [1] http://www.unicode.org/iuc/iuc22/a365.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
unicode-bidi and FOP 2.0?
In the fop-dev archive at marc.theaimsgroup.com, the references that I can find to unicode-bidi amount to little more than an acknowledgement of its inclusion in the XSL spec. Is there yet any indication whether unicode-bidi, or the Unicode bidirectional algorithm, will be implemented as part of FOP 2.0? Regards, Tony Graham Tony Graham mailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
