Re: fo:inline bpd

[Finn Bock]

[Manuel]

Inline areas have their own line-height trait which can be different to 
the line-height on the containing line area / containing block. 
line-height when specified on an inline fo has a different meaning, 
i.e. the inline area returned MUST have the exact line-height as 
specified, while line-height on a block level sets the minimum height 
for all decendant inline areas. We don't do any of that in the moment. 
Side note: in layout we don't know any more if a property is inherited 
or specified on that element, that could be a complication here. Finn, 
any thoughts on this?


You mean the phrases: "If the property is set on an inline-level 
element, it specifies ..." is only used when the line-height property is 
explicitly set on inline-level? If the line-height is inherited then 
that paragraph isn't operative?


If that is the case, then line-height is the only(?) property that isn't 
using the specified value. Strange. But is it not a big deal, the 
inline-level .bind() method will have to check if the line-height is 
explicit set:


   lineHeightExplicit = pList.getExplicit(PR_LINE_HEIGHT);

which is then non-null is the property is set on the element. However it 
is a huge deviation from the rest of the properties.


regards,
finn

Re: Space-resolution doesn't work

[Jeremias Maerki]

FYI, I'm going to try reimplementing the whole space-resolution part on
the block-progression-dimension (to start with) using the inputs from
both Luca and Simon and based on my findings I've documented in the
Wiki:
http://wiki.apache.org/xmlgraphics-fop/SpaceResolution

I've started by creating a base class "UnresolvedElement" (holding a
Position instance) from which SpaceElement (holding SpaceProperty) and
BorderOrPaddingElement (holding a CondLengthProperty) are derived. We'll
see how well this turns out.

On 09.09.2005 11:07:56 Jeremias Maerki wrote:
> 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



Jeremias Maerki

Re: svn commit: r280520 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java

[Luca Furini]

I wrote:

Factorized the creation of the elements in TextLM: now both getNextKE() 
and getChangedKE() > call the same methods createElementsForASpace() and 
crateElementsForAWordFragment().


This should definitively solve bug 36533.


Besides removing duplicated lines and inconsistencies, I hope this could 
help making this part of code a little more readable and easily 
understandable.


I'm going to see if these methods can be moved up to the LeafNodeLM, thus 
being available for all subclasses.


Manuel, I hope you don't have to spend a lot of time merging this changes 
with the work you are doing; I think you could add further parameters to 
createElementsForASpace(), to pass the variables you need for borders and 
padding.


Regards
Luca

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

[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=36533





--- Additional Comments From [EMAIL PROTECTED]  2005-09-13 11:12 ---
The commit r280520 has removed duplicated lines in the methods 
getNextKnuthElements() and getChangedKnuthElements(), solving this bug 
definitively ... I hope! ;-)

I'm leaving this issue "reopened", as I want to check the behaviour of other 
formatting objects which could have similar problems, especially fo:character.

-- 
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: fo:inline bpd

[Manuel Mall]

On Tue, 13 Sep 2005 04:12 pm, Finn Bock wrote:
> [Manuel]
>
> > Inline areas have their own line-height trait which can be
> > different to the line-height on the containing line area /
> > containing block. line-height when specified on an inline fo has a
> > different meaning, i.e. the inline area returned MUST have the
> > exact line-height as specified, while line-height on a block level
> > sets the minimum height for all decendant inline areas. We don't do
> > any of that in the moment. Side note: in layout we don't know any
> > more if a property is inherited or specified on that element, that
> > could be a complication here. Finn, any thoughts on this?
>
> You mean the phrases: "If the property is set on an inline-level
> element, it specifies ..." is only used when the line-height property
> is explicitly set on inline-level? If the line-height is inherited
> then that paragraph isn't operative?

Yes that's how I read it because otherwise the sentence "If the property 
is set on an inline-level element, it specifies ..." doesn't make sense 
to me. As the property is always implicitly set so this must mean 
explicit.

Do you (or anyone else) understand that differently?

>
> If that is the case, then line-height is the only(?) property that
> isn't using the specified value. Strange. But is it not a big deal,
> the inline-level .bind() method will have to check if the line-height
> is explicit set:
>
> lineHeightExplicit = pList.getExplicit(PR_LINE_HEIGHT);
>
> which is then non-null is the property is set on the element. However
> it is a huge deviation from the rest of the properties.

Yes it appears to be.
>
> regards,
> finn

Manuel

Re: svn commit: r280520 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java

[Manuel Mall]

On Tue, 13 Sep 2005 05:04 pm, Luca Furini wrote:
> I wrote:

> Manuel, I hope you don't have to spend a lot of time merging this
> changes with the work you are doing; I think you could add further
> parameters to createElementsForASpace(), to pass the variables you
> need for borders and padding.
>
Luca, no problem - merged my stuff with your new Text LM.

> Regards
>  Luca
Manuel

Re: fo:inline bpd

[Finn Bock]

Manuel Mall wrote:


On Tue, 13 Sep 2005 04:12 pm, Finn Bock wrote:


[Manuel]



Inline areas have their own line-height trait which can be
different to the line-height on the containing line area /
containing block. line-height when specified on an inline fo has a
different meaning, i.e. the inline area returned MUST have the
exact line-height as specified, while line-height on a block level
sets the minimum height for all decendant inline areas. We don't do
any of that in the moment. Side note: in layout we don't know any
more if a property is inherited or specified on that element, that
could be a complication here. Finn, any thoughts on this?


You mean the phrases: "If the property is set on an inline-level
element, it specifies ..." is only used when the line-height property
is explicitly set on inline-level? If the line-height is inherited
then that paragraph isn't operative?


[Manuel]

Yes that's how I read it because otherwise the sentence "If the property 
is set on an inline-level element, it specifies ..." doesn't make sense 
to me. As the property is always implicitly set so this must mean 
explicit.


Do you (or anyone else) understand that differently?


Hmm, not speaking english natively puts me in a disadvantage, but 
perhaps the sentence means the same as "If the property is *used* on an 
inline-level element, it specifies ..." ? The focus is merely on the 
element type, not on where the property value comes from.


regards,
finn

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Jeremias Maerki wrote:

> > BTW, are these fonts well defined in the postscript standard? Or do 
> > they only exist in PDF?
> 
> PDF was derived from PostScript, so yes, they are well-defined.

There is a group of so-called Base-35 fonts for PostScript that is a
superset of the Base-14 fonts. I was always under the impression that
PostScript implementations were required to support them just as PDF
Renderers are required to support the Base-14. However, I am currently under
the impression that the Base-35 is more of a convention than a standard, so
it may not be quite as well-defined, but it is probably reasonable to assume
that they are there.

> If the current approach is very difficult to implement, then 
> I think it's best to use the approach with the renderer hint. 

IIUC, the current approach is to define all fonts that are registered and to
embed all that are not Base-14. That is not too difficult to implement, but
I think Vincent's point was that it seemed wrong. It would not be too hard
to add a method that provides a collection of all registered fonts, but the
Font objects returned must actually be parsed, which could be a lot of
wasted overhead. The question would be whether that should be a standard
aXSL method or whether it should be viewed as a hack that would just require
an extension to FOrayFontServer.

Since I gather that FOP will not be supporting the reuse of a FontServer
instance (i.e. each document will have its own instance of FontServer),
perhaps it works fine to just have the user provide a separate
font-configuration file that contains only the fonts needed for the
document.

> I can implement that for you if you want. Only referring to 
> the font name will not work since we currently have to 
> reencode each font to the WinAnsi charset.
> And since each PostScript page should be self-sufficient and 
> removable, we can't do this reencoding when the font appears 
> for the first time.

Actually, you are no longer tied to WinAnsi. We have a lot more flexibility
on encodings than before:
1. All of the predefined encodings for both PostScript and PDF are available
to either platform -- of course, if they are not predefined for the platform
used, they must be written into the output.
2. Both platforms have access to the font's internal encoding.
3. The user can specify custom encodings through the font-configuration
file.

So, if a PostScript document can use the font's internal encoding, and if
the font is known to already be available to the interpreter, I think it
could safely be used by name. But perhaps I have forgotten something.

This may require a new font-configuration item for the font element that
allows it to tell whether it is known to be available to the PostScript
interpreter. There are some other possibilities here as well.

Anyway, there are some more options for you to consider.

Victor Mote

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

[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=36533





--- Additional Comments From [EMAIL PROTECTED]  2005-09-13 16:04 ---
Sorry Luca, I don't want to annoy you (really), but I think I found another 
problem (actually two problems).

1. Under text-align=right and hyphenation we are now 2780mpt (= one space) 
short. You got rid of the excessive spaces and now we are missing one :-). I'll 
attach a testcase for it.

2. If you uncomment the second block in the test (or make the first block text-
align="center") you get a ClassCastException on a LeafNodePosition.

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

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

[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=36533





--- Additional Comments From [EMAIL PROTECTED]  2005-09-13 16:06 ---
Created an attachment (id=16392)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16392&action=view)
Testcase xml file

You need to have OFFO fop-hyph.jar in the classpath for the problem to show.

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

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

[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=36533





--- Additional Comments From [EMAIL PROTECTED]  2005-09-13 16:06 ---
Created an attachment (id=16393)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16393&action=view)
PDF generated from attachment #16392


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

DO NOT REPLY [Bug 36533] - Incorrect ipd and twsadjust settings

[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=36533





--- Additional Comments From [EMAIL PROTECTED]  2005-09-13 16:32 ---
Well, it seems I was right (at least) in leaving this issue open! :-)

Thanks for your quick feedback, I'm going to see what happens ...

-- 
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: fo:inline bpd

[Manuel Mall]

On Tue, 13 Sep 2005 06:56 pm, Finn Bock wrote:
> Manuel Mall wrote:
> > On Tue, 13 Sep 2005 04:12 pm, Finn Bock wrote:
> >>[Manuel]
> >>
> >>>Inline areas have their own line-height trait which can be
> >>>different to the line-height on the containing line area /
> >>>containing block. line-height when specified on an inline fo has a
> >>>different meaning, i.e. the inline area returned MUST have the
> >>>exact line-height as specified, while line-height on a block level
> >>>sets the minimum height for all decendant inline areas. We don't
> >>> do any of that in the moment. Side note: in layout we don't know
> >>> any more if a property is inherited or specified on that element,
> >>> that could be a complication here. Finn, any thoughts on this?
> >>
> >>You mean the phrases: "If the property is set on an inline-level
> >>element, it specifies ..." is only used when the line-height
> >> property is explicitly set on inline-level? If the line-height is
> >> inherited then that paragraph isn't operative?
>
> [Manuel]
>
> > Yes that's how I read it because otherwise the sentence "If the
> > property is set on an inline-level element, it specifies ..."
> > doesn't make sense to me. As the property is always implicitly set
> > so this must mean explicit.
> >
> > Do you (or anyone else) understand that differently?
>
> Hmm, not speaking english natively puts me in a disadvantage, but
> perhaps the sentence means the same as "If the property is *used* on
> an inline-level element, it specifies ..." ? The focus is merely on
> the element type, not on where the property value comes from.
>
That puts us on a level playing field as english is not my native 
language either (although having now lived in Australia for 20 years 
one does acquire a certain familiarity with the language here).

Any way, back to the topic at hand. Lets assume the following fo:

some 10pt textsome 12 pt textmore 10pt 
text

In this case the line-height everywhere is normal which is equivalent to 
1.2em. The innermost fo:inline will return an area with a bpd of 12pt. 
However, the outer fo:inline has a smaller font and as the line-height 
spec on an inline element is binding it can only return areas of 10pt 
bpd therefore "cutting off" part of the inner fo:inline. So our area 
tree (assuming it all fits on one line) in fop terminology would look 
like:


  
some 10pt text

  some 12pt text

more 10pt text
  


In my interpretation as there is no explicit line-height spec on the 
inlines we get an area tree like:


  
some 10pt text

  some 12pt text

more 10pt text
  


I have no idea whose right or wrong here or even which interpretation 
makes more sense.

BTW, fop does in the moment neither of the two above - but that's a 
different story.

> regards,
> finn

Manuel

Re: PSDocumentGraphics2D and Font dictionary

[Jeremias Maerki]

On 13.09.2005 15:47:12 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > > BTW, are these fonts well defined in the postscript standard? Or do 
> > > they only exist in PDF?
> > 
> > PDF was derived from PostScript, so yes, they are well-defined.
> 
> There is a group of so-called Base-35 fonts for PostScript that is a
> superset of the Base-14 fonts. I was always under the impression that
> PostScript implementations were required to support them just as PDF
> Renderers are required to support the Base-14. However, I am currently under
> the impression that the Base-35 is more of a convention than a standard, so
> it may not be quite as well-defined, but it is probably reasonable to assume
> that they are there.

I just found this: Appendix E of the PS bible, uhm, PostScript Language
Reference (third edition) says: "While there is not a standard set of
fonts that is required by the PostScript language, most PostScript
products include software for 13 standard fonts from the Times,
Helvetica, Courier and Symbol families."

Looks like you can't even be 100% sure that the base 14 fonts are
available.

> > If the current approach is very difficult to implement, then 
> > I think it's best to use the approach with the renderer hint. 
> 
> IIUC, the current approach is to define all fonts that are registered and to
> embed all that are not Base-14. That is not too difficult to implement, but
> I think Vincent's point was that it seemed wrong. It would not be too hard
> to add a method that provides a collection of all registered fonts, but the
> Font objects returned must actually be parsed, which could be a lot of
> wasted overhead. The question would be whether that should be a standard
> aXSL method or whether it should be viewed as a hack that would just require
> an extension to FOrayFontServer.

Let's look at it from another side. If someone writes some kind of FO
editor or a configuration tool for FOray/FOP a method that reports all
available fonts will certainly be useful. :-)

> Since I gather that FOP will not be supporting the reuse of a FontServer
> instance (i.e. each document will have its own instance of FontServer),
> perhaps it works fine to just have the user provide a separate
> font-configuration file that contains only the fonts needed for the
> document.

No, I think there will definitely come a point in time where I will
want some kind of object holding on to global font configuration but
which is not a static mechanism. Although it's possible to reuse the
FOUserAgent, the user agent IMO is something that is bound to a
rendering run. We simply haven't finalized the API, yet, or I'm at least
not ready to call it finalized. :-)

> > I can implement that for you if you want. Only referring to 
> > the font name will not work since we currently have to 
> > reencode each font to the WinAnsi charset.
> > And since each PostScript page should be self-sufficient and 
> > removable, we can't do this reencoding when the font appears 
> > for the first time.
> 
> Actually, you are no longer tied to WinAnsi. We have a lot more flexibility
> on encodings than before:
> 1. All of the predefined encodings for both PostScript and PDF are available
> to either platform -- of course, if they are not predefined for the platform
> used, they must be written into the output.
> 2. Both platforms have access to the font's internal encoding.
> 3. The user can specify custom encodings through the font-configuration
> file.
> 
> So, if a PostScript document can use the font's internal encoding, and if
> the font is known to already be available to the interpreter, I think it
> could safely be used by name. But perhaps I have forgotten something.

No, that's true. I simply haven't cared, yet, about finding out how
glyphs are accessed on-the-fly in PS that are not accessible through the
encoding. Rewriting the encoding seemed easier.

> This may require a new font-configuration item for the font element that
> allows it to tell whether it is known to be available to the PostScript
> interpreter. There are some other possibilities here as well.

I bet. Sounds good.

> Anyway, there are some more options for you to consider.

We're surely not going to run out of discussion topics and things to do.
:-) Thanks for your input.

Jeremias Maerki

Re: fo:inline bpd

[Finn Bock]

[Manuel]


Any way, back to the topic at hand. Lets assume the following fo:

some 10pt textfont-size="12pt">some 12 pt textmore 10pt 
text


In this case the line-height everywhere is normal which is equivalent to 
1.2em. The innermost fo:inline will return an area with a bpd of 12pt. 
However, the outer fo:inline has a smaller font and as the line-height 
spec on an inline element is binding it can only return areas of 10pt 
bpd therefore "cutting off" part of the inner fo:inline. So our area 
tree (assuming it all fits on one line) in fop terminology would look 
like:



  
some 10pt text

  some 12pt text

more 10pt text
  



Right, except the 1 and 12000 values should be text-altitude + 
text-depth:



  
some 10pt text

  some 12pt text

more 10pt text
  


All the inline areas also have a line-height trait of 12000 but that is 
only used when lls="line-height" [4.6].


In my interpretation as there is no explicit line-height spec on the 
inlines we get an area tree like:



  
some 10pt text

  some 12pt text

more 10pt text
  


I have no idea whose right or wrong here or even which interpretation 
makes more sense.


From [4.6]:
"""An inline-area with inline-area children has a content-rectangle 
which extends from its dominant baseline (see [4.2.6 Font Baseline 
Tables]) by its text-depth in the block-progression-direction, and in 
the opposite direction by its text-altitude;"""


So it appears that the bpd of an inline depends on the inline's font and 
not on the line-height property or the inline's children.


Does it make sense?


I have no idea what the spec means by [7.15.4]:

"""If the property is set on an inline-level element, it specifies the 
exact height of each box generated by the element."""


because both "set" and "box" is undefined by the rest of the spec. The 
text is copied from CSS where it perhaps makes sense.


regards,
finn

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Jeremias Maerki wrote:

> Looks like you can't even be 100% sure that the base 14 fonts 
> are available.

Right.

> Let's look at it from another side. If someone writes some 
> kind of FO editor or a configuration tool for FOray/FOP a 
> method that reports all available fonts will certainly be useful. :-)

OK. That makes sense. To avoid wasteful parsing, it will mean that at least
3 new classes need to be exposed through interfaces (RegisteredFont,
RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing
anyway.

> > Since I gather that FOP will not be supporting the reuse of a 
> > FontServer instance (i.e. each document will have its own 
> instance of 
> > FontServer), perhaps it works fine to just have the user provide a 
> > separate font-configuration file that contains only the 
> fonts needed 
> > for the document.
> 
> No, I think there will definitely come a point in time where 
> I will want some kind of object holding on to global font 
> configuration but which is not a static mechanism. Although 
> it's possible to reuse the FOUserAgent, the user agent IMO is 
> something that is bound to a rendering run. We simply haven't 
> finalized the API, yet, or I'm at least not ready to call it 
> finalized. :-)

Very good. It sounds like you and I may end up with API visions that match
better than I might have thought at one time.

> > Actually, you are no longer tied to WinAnsi. We have a lot more 
> > flexibility on encodings than before:
> > 1. All of the predefined encodings for both PostScript and PDF are 
> > available to either platform -- of course, if they are not 
> predefined 
> > for the platform used, they must be written into the output.
> > 2. Both platforms have access to the font's internal encoding.
> > 3. The user can specify custom encodings through the 
> > font-configuration file.
> > 
> > So, if a PostScript document can use the font's internal 
> encoding, and 
> > if the font is known to already be available to the interpreter, I 
> > think it could safely be used by name. But perhaps I have 
> forgotten something.
> 
> No, that's true. I simply haven't cared, yet, about finding 
> out how glyphs are accessed on-the-fly in PS that are not 
> accessible through the encoding. Rewriting the encoding seemed easier.

I am very sure that for Type 1 fonts, specifying another encoding is the
only way to get it done. There is just no way to get more than 256
combinations out of 8 bits and there is no way to get more than 8 bits.
However, the good news is that I am 99% sure that for both PDF and
PostScript you can specify the same underlying font with two (or more)
different encodings. They will actually show up as two different font
"objects" in the document and must of course be referred to that way also.
I'll let you know how that turns out.

> > This may require a new font-configuration item for the font element 
> > that allows it to tell whether it is known to be available to the 
> > PostScript interpreter. There are some other possibilities 
> here as well.
> 
> I bet. Sounds good.

The more I think about it, encapsulating the characteristics of a specific
PostScript interpreter is probably the "right" way to go. Then the rendering
run can use that to decide whether the font needs to be embedded or not.
I'll have to ponder that for awhile.

Victor Mote

FOTree test question

[Andreas L Delmelle]

Hi,

I can describe the case only, since I can't commit my changes yet (they 
still break a few layout tests), so please ask further if you don't 
have enough info to form an idea of my changes.
Maybe better to wait to when I commit my stuff to a branch --tomorrow 
or Thursday--, so you get a clearer view, but anyway...


Sketch of the changes:
In my local copy, I have added a new Maker subclass for the 
column-number property.
It works in combination with an added columnIndex instance variable in 
the related FObjs (Table/TableBody/TableRow), which is updated in 
addChildNode() (if the child-node is a TableColumn/TableCell).


Very roughly, the new ColumnNumberProperty.make() does something like 
this:


if( fo.getNameId() == FO_TABLE_CELL || fo.getNameId() == 
FO_TABLE_COLUMN ) {

   //return the parent's current columnIndex
} else {
   //tried two things here:
   //1) return null
   //2) throw a PropertyException
}

All seems to work nicely if I trace it using log.debug(), but I wanted 
to include some junit tests.


Problem is that the tests fail because:
- either an exception is thrown because the property is specified on 
'null'

- or the property evaluates to 'null' instead of the expected '1'.

The related fragments of the test-case look like:


  

...

  
  cell content



Any idea what I am missing/doing wrong? Any insights appreciated.

TIA!

Cheers,

Andreas

Re: svn commit: r280608 - /xmlgraphics/fop/trunk/test/java/org/apache/fop/fotreetest/ext/AssertElement.java

[Andreas L Delmelle]

On Sep 13, 2005, at 19:58, [EMAIL PROTECTED] wrote:


Author: bckfnn
Date: Tue Sep 13 10:57:58 2005
New Revision: 280608

URL: http://svn.apache.org/viewcvs?rev=280608&view=rev
Log:
Run the checks on the parent's propertyList.


OK, so it wasn't me after all... :-)

Thanks a lot for the very quick response!!!


Cheers,

Andreas

Re: PSDocumentGraphics2D and Font dictionary

[Vincent Hennebert]

Let's look at it from another side. If someone writes some 
kind of FO editor or a configuration tool for FOray/FOP a 
method that reports all available fonts will certainly be useful. :-)


OK. That makes sense. To avoid wasteful parsing, it will mean that at least
3 new classes need to be exposed through interfaces (RegisteredFont,
RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing
anyway.


Yes, I think it could be interesting. It would also be necessary to add 
getStream methods, now that font parsing is delegated to the font server. 
Currently there is only one getPDFFontFileStream method. There should perhaps be 
also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that 
the client is unable to make font subsetting with the current interface.


RegisteredFontFamily and RegisteredFontDesc might also be interesting for the 
AWT renderer, but that's another purpose. I'll perhaps come back on this later.



(more below)


Very good. It sounds like you and I may end up with API visions that match
better than I might have thought at one time.


Actually, you are no longer tied to WinAnsi. We have a lot more 
flexibility on encodings than before:
1. All of the predefined encodings for both PostScript and PDF are 
available to either platform -- of course, if they are not 


predefined 


for the platform used, they must be written into the output.
2. Both platforms have access to the font's internal encoding.
3. The user can specify custom encodings through the 
font-configuration file.


So, if a PostScript document can use the font's internal 


encoding, and 

if the font is known to already be available to the interpreter, I 
think it could safely be used by name. But perhaps I have 


forgotten something.

No, that's true. I simply haven't cared, yet, about finding 
out how glyphs are accessed on-the-fly in PS that are not 
accessible through the encoding. Rewriting the encoding seemed easier.



I am very sure that for Type 1 fonts, specifying another encoding is the
only way to get it done. There is just no way to get more than 256
combinations out of 8 bits and there is no way to get more than 8 bits.
However, the good news is that I am 99% sure that for both PDF and
PostScript you can specify the same underlying font with two (or more)
different encodings. They will actually show up as two different font
"objects" in the document and must of course be referred to that way also.
I'll let you know how that turns out.


This may require a new font-configuration item for the font element 
that allows it to tell whether it is known to be available to the 
PostScript interpreter. There are some other possibilities 


here as well.

I bet. Sounds good.



The more I think about it, encapsulating the characteristics of a specific
PostScript interpreter is probably the "right" way to go. Then the rendering
run can use that to decide whether the font needs to be embedded or not.
I'll have to ponder that for awhile.


Here I'm beginning to get lost because I don't know the Postscript standard.


My hope to get ready before the upcoming realease starts vanishing... :-(
Here's my summary of the current discussion:
1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS 
file, even those that will never be used. It does this by parsing itself the 
font files;
2. I can't reproduce this behavior with aXSL and FOray easily, because I've no 
direct access to the font files;
3. Still doing this would require hacking the FOrayFont subpackage; that would 
result in something dirty but that should work;
4. Anyway there are several improvements to bring to the PS renderer: mainly 
character encoding, font embedding and in a longer term two-pass rendering for a 
proper font handling.


Now I'm thinking of the next release: simply putting the font name in the 
postscript file would be rather straightforward to implement, and should work 
for most of cases (?), thanks to the non-standard but well-known base14 (and 
even base35) font set. But that's definitely a regression from the current state.
Improving the PS renderer to allow proper embedding will require (1) changes to 
 the aXSL interfaces (so a certain amount of discussions), (2) me to learn 
Postscript. That would prevent the FOrayFont subsystem from being integrated in 
the pre-release.


Do you agree with my summary?

Integrating FOrayFont in the pre-release would be great...
Deciding to delay the integration would give me more time to investigate the 
insides of FOrayFont, learn PS and PDF standards and so do things much better.


If there is a decision to make it does not belong to me...
Vincent

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Vincent Hennebert wrote:

> > OK. That makes sense. To avoid wasteful parsing, it will 
> mean that at 
> > least
> > 3 new classes need to be exposed through interfaces 
> (RegisteredFont, 
> > RegisteredFontFamily, and RegisteredFontDesc), which may be a good 
> > thing anyway.
> 
> Yes, I think it could be interesting. It would also be 
> necessary to add getStream methods, now that font parsing is 
> delegated to the font server. 
> Currently there is only one getPDFFontFileStream method. 
> There should perhaps be also a getPSFontFileStream, and 
> something like getPDF/PSSubset? It seems that the client is 
> unable to make font subsetting with the current interface.

OK. I have actually not been sure how much of the code is reusable between
the two. PS rendering is way lower on my priority list than PDF, so I don't
work with it much. Here is our decision tree:

if (PS font embedding works in FOP now) {
if (it been added since May, 2004, when I forked the FOP code) {
we need to patch FOray with that logic;
} else {
Victor somehow lost this in the refactoring work;
FOray still needs to be patched;
}
} else {
we can add PS font embedding later;
}

I am not sure what you mean "getPDF/PSSubset".

> > The more I think about it, encapsulating the 
> characteristics of a specific
> > PostScript interpreter is probably the "right" way to go. 
> Then the rendering
> > run can use that to decide whether the font needs to be 
> embedded or not.
> > I'll have to ponder that for awhile.
> 
> Here I'm beginning to get lost because I don't know the 
> Postscript standard.
> 
> 
> My hope to get ready before the upcoming realease starts 
> vanishing... :-(
> Here's my summary of the current discussion:
> 1. Currently the Fop PSRenderer embeds all of the configured 
> fonts in the PS 
> file, even those that will never be used. It does this by 
> parsing itself the 
> font files;

Hmmm. I think something has changed here since I last looked at it.
Jeremias?

> 2. I can't reproduce this behavior with aXSL and FOray 
> easily, because I've no 
> direct access to the font files;

Point me to the FOP code that does the embedding, class name(s) and line
numbers, and I'll see if I can extract it into an aXSL-exposed method.

> 3. Still doing this would require hacking the FOrayFont 
> subpackage; that would 
> result in something dirty but that should work;

Better would be to just make aXSL provide what needs to be provided. If we
can hack FOray to do it, then we should be able to expose what is needed.
Since nothing we are talking about here is a pollution of the interface, we
should just be able to change the interface.

> 4. Anyway there are several improvements to bring to the PS 
> renderer: mainly 
> character encoding, font embedding and in a longer term 
> two-pass rendering for a 
> proper font handling.

OK. I am confused. I thought above that font embedding worked in PS now, but
this seems to indicate that it does not.

> Now I'm thinking of the next release: simply putting the font 
> name in the 
> postscript file would be rather straightforward to implement, 
> and should work 
> for most of cases (?), thanks to the non-standard but 
> well-known base14 (and 
> even base35) font set. But that's definitely a regression 
> from the current state.
> Improving the PS renderer to allow proper embedding will 
> require (1) changes to 
>   the aXSL interfaces (so a certain amount of discussions), 
> (2) me to learn 
> Postscript. That would prevent the FOrayFont subsystem from 
> being integrated in 
> the pre-release.
> 
> Do you agree with my summary?

I can take some of this burden off of you, in that I can hopefully fix aXSL
and FOray to provide what is needed. If that is done well, you shouldn't
need to learn too much PostScript to get it to work, and perhaps one of the
other developers can help you get it glued in. I don't know how much work it
will take for me to get the FOray PS Renderer working (it may work now), I
can use that as a test bed also.

Even if we can't get PS embedding working in time for the release (and I
think we should be able to), I am not sure whether this is a step backwards
from 0.20.5. I can't imagine that I just totally yanked PS embedding code
out of the FOray PS renderer.

> Integrating FOrayFont in the pre-release would be great...
> Deciding to delay the integration would give me more time to 
> investigate the 
> insides of FOrayFont, learn PS and PDF standards and so do 
> things much better.
> 
> If there is a decision to make it does not belong to me...
> Vincent

Nor to me. I'll just try to help get working what you need and let you guys
decide what works best.

Victor Mote

Re: FOTree test question

[Finn Bock]

[Andreas]


Very roughly, the new ColumnNumberProperty.make() does something like this:


That should be ColumnNumberPropertyMaker in order to follow the naming 
of all the other custom makers.


regards,
finn

Re: PSDocumentGraphics2D and Font dictionary

[Jeremias Maerki]

On 13.09.2005 20:57:31 Vincent Hennebert wrote:
> >>Let's look at it from another side. If someone writes some 
> >>kind of FO editor or a configuration tool for FOray/FOP a 
> >>method that reports all available fonts will certainly be useful. :-)
> > 
> > OK. That makes sense. To avoid wasteful parsing, it will mean that at least
> > 3 new classes need to be exposed through interfaces (RegisteredFont,
> > RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing
> > anyway.
> 
> Yes, I think it could be interesting. It would also be necessary to add 
> getStream methods, now that font parsing is delegated to the font server. 
> Currently there is only one getPDFFontFileStream method. There should perhaps 
> be 
> also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that 
> the client is unable to make font subsetting with the current interface.

And what about PCL? And SVG? And AFP? IMO, output format specific code
should not appear in the main interfaces for font access. Every target
platform will have their little specialities: special font formats, font
conversions may be necessary (Type 1 to SVG fonts, SVG fonts to Type 3).
It makes sense to write font embedding code directly in the renderer.
The font provider can certainly make the job easier by providing access
to often-used data and especially to the raw font streams. But that may
be limited to certain aspects of a font type or dependant on the font
subsystem implementation. Providing a font to a layout engine has also
different requirements than embedding or using a font in a specific
output format. Maybe the Font interface should simply have a method to
return a very generic interface for more detailed and font- and
output-system-specific access to the font. Consumers of this interface
can then cast it to a special interface/class. Something like:
TargetFormatHelper Font.getTargetFormatHelper(String mime)
Subclasses of TargetFormatHelper could be PDFTargetFormatHelper
or a PSTargetFormatHelper. The Font interface in aXSL seems to be
overloaded already, so this might be an improvement anyway.



> > The more I think about it, encapsulating the characteristics of a specific
> > PostScript interpreter is probably the "right" way to go. Then the rendering
> > run can use that to decide whether the font needs to be embedded or not.
> > I'll have to ponder that for awhile.
> 
> Here I'm beginning to get lost because I don't know the Postscript standard.
> 
> 
> My hope to get ready before the upcoming realease starts vanishing... :-(

It's a complex problem area. I'm not surprised.

> Here's my summary of the current discussion:
> 1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS 
> file, even those that will never be used. It does this by parsing itself the 
> font files;
> 2. I can't reproduce this behavior with aXSL and FOray easily, because I've 
> no 
> direct access to the font files;

Which is a problem IMO. See my comments above.

> 3. Still doing this would require hacking the FOrayFont subpackage; that 
> would 
> result in something dirty but that should work;

I believe this can be designed in way that is even cleaner than it is
now. I just wish I had time to participate but my priorities make that
impossible.

> 4. Anyway there are several improvements to bring to the PS renderer: mainly 
> character encoding, font embedding and in a longer term two-pass rendering 
> for a 
> proper font handling.
> 
> Now I'm thinking of the next release: simply putting the font name in the 
> postscript file would be rather straightforward to implement, and should work 
> for most of cases (?), thanks to the non-standard but well-known base14 (and 
> even base35) font set.

Without the knowledge on how to access a glyph outside the default
encoding, characters like the very important Euro character will be
impossible to produce.

> But that's definitely a regression from the current state.
> Improving the PS renderer to allow proper embedding will require (1) changes 
> to 
>   the aXSL interfaces (so a certain amount of discussions), (2) me to learn 
> Postscript. That would prevent the FOrayFont subsystem from being integrated 
> in 
> the pre-release.

If aXSL-font provides access to the raw underlying font streams, that
problem basically dissolves. The following would certainly be no
problem:
InputStream Font.getRawStream(String part) where part may be "pfb", "pfm",
"afm", "ttf" etc.

> Do you agree with my summary?
> 
> Integrating FOrayFont in the pre-release would be great...

Quite unrealistic as it stands now, sorry.

> Deciding to delay the integration would give me more time to investigate the 
> insides of FOrayFont, learn PS and PDF standards and so do things much better.
> 
> If there is a decision to make it does not belong to me...

Look, the first preview release doesn't have to be perfect. It's simply
a first big sign to the outside world that FOP is not dead but is
instead

Re: PSDocumentGraphics2D and Font dictionary

[Jeremias Maerki]

On 13.09.2005 21:47:01 Victor Mote wrote:

> > 1. Currently the Fop PSRenderer embeds all of the configured 
> > fonts in the PS 
> > file, even those that will never be used. It does this by 
> > parsing itself the 
> > font files;
> 
> Hmmm. I think something has changed here since I last looked at it.
> Jeremias?

I have recently implemented Type 1 embedding for those fonts which have
the PFB file specified. Before that all Type 1 fonts were only
referenced, their encoding redefined to WinAnsi and assigned a font key
which is used inside the pages.




Jeremias Maerki

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Jeremias Maerki wrote:

> And what about PCL? And SVG? And AFP? IMO, output format 
> specific code should not appear in the main interfaces for 
> font access. Every target platform will have their little 
> specialities: special font formats, font conversions may be 
> necessary (Type 1 to SVG fonts, SVG fonts to Type 3).
> It makes sense to write font embedding code directly in the renderer.
> The font provider can certainly make the job easier by 
> providing access to often-used data and especially to the raw 
> font streams. But that may be limited to certain aspects of a 
> font type or dependant on the font subsystem implementation. 
> Providing a font to a layout engine has also different 
> requirements than embedding or using a font in a specific 

I agree with all of this, and this type of project is somewhere way down my
mental to-do list. However, it requires more knowledge than I have of all of
the various rendering possibilities to be able to factor out the
lowest-common-denominator. The existing methods can best be thought of as
workarounds.

> output format. Maybe the Font interface should simply have a 
> method to return a very generic interface for more detailed 
> and font- and output-system-specific access to the font. 
> Consumers of this interface can then cast it to a special 
> interface/class. Something like:
> TargetFormatHelper Font.getTargetFormatHelper(String mime) 
> Subclasses of TargetFormatHelper could be 
> PDFTargetFormatHelper or a PSTargetFormatHelper. The Font 

This is an interesting idea, but, if I understand it correctly, breaks
pluggability.

> interface in aXSL seems to be overloaded already, so this 
> might be an improvement anyway.

I don't understand this comment. It is a high-level abstraction.

> > Here's my summary of the current discussion:
> > 1. Currently the Fop PSRenderer embeds all of the 
> configured fonts in 
> > the PS file, even those that will never be used. It does this by 
> > parsing itself the font files; 2. I can't reproduce this 
> behavior with 
> > aXSL and FOray easily, because I've no direct access to the font 
> > files;
> 
> Which is a problem IMO. See my comments above.

I *really* don't understand this. The whole point of the font subsystem is
to hide as much detail as possible from the client application. If you want
access to the raw font data, then perhaps the FOP 0.20.5 approach is better
for what you need??!!

> > 3. Still doing this would require hacking the FOrayFont subpackage; 
> > that would result in something dirty but that should work;
> 
> I believe this can be designed in way that is even cleaner 
> than it is now. I just wish I had time to participate but my 
> priorities make that impossible.
> 
> > 4. Anyway there are several improvements to bring to the PS 
> renderer: 
> > mainly character encoding, font embedding and in a longer term 
> > two-pass rendering for a proper font handling.
> > 
> > Now I'm thinking of the next release: simply putting the 
> font name in 
> > the postscript file would be rather straightforward to 
> implement, and 
> > should work for most of cases (?), thanks to the non-standard but 
> > well-known base14 (and even base35) font set.
> 
> Without the knowledge on how to access a glyph outside the 
> default encoding, characters like the very important Euro 
> character will be impossible to produce.

Again, I am lost. The *only* way you get to characters outside the standard
encoding is to specify a different encoding. We know how to do that.

> > But that's definitely a regression from the current state.
> > Improving the PS renderer to allow proper embedding will 
> require (1) changes to 
> >   the aXSL interfaces (so a certain amount of discussions), 
> (2) me to 
> > learn Postscript. That would prevent the FOrayFont subsystem from 
> > being integrated in the pre-release.
> 
> If aXSL-font provides access to the raw underlying font 
> streams, that problem basically dissolves. The following 
> would certainly be no
> problem:
> InputStream Font.getRawStream(String part) where part may be 
> "pfb", "pfm", "afm", "ttf" etc.

Is this just for embedding purposes, or do you intend to parse it? If you
want to parse it, why? If all you want to do is embed it, why do you want
the metrics files? FOray essentially provides the raw font stream now. It
works for PDF, but, if I understand Vincent correctly, does not work for PS.
So how does this method you suggest help that?

> > Do you agree with my summary?
> > 
> > Integrating FOrayFont in the pre-release would be great...
> 
> Quite unrealistic as it stands now, sorry.

That is your (FOP's) decision, but it makes no sense to me. You are willing
to go backwards in almost any other area, but are unwilling to *not* go
forwards with PostScript font embedding? Even when it is doable?

Still, I appreciate knowing. I'll shift my focus back to getting my FOray
release out the door.

Victor Mote

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Jeremias Maerki wrote:

> I have recently implemented Type 1 embedding for those fonts 
> which have the PFB file specified. Before that all Type 1 
> fonts were only referenced, their encoding redefined to 
> WinAnsi and assigned a font key which is used inside the pages.

OK. That should make it pretty easy for someone to patch FOray to do
something similar. I'll get to it when I can.

Victor Mote

Re: FOTree test question

[Andreas L Delmelle]

On Sep 13, 2005, at 22:06, Finn Bock wrote:


[Andreas]

Very roughly, the new ColumnNumberProperty.make() does something like 
this:


That should be ColumnNumberPropertyMaker in order to follow the naming 
of all the other custom makers.


OK, I'll keep that in mind... Shouldn't it be 
TableBorderPrecedenceMaker as well then?


Cheers,

Andreas

Re: PSDocumentGraphics2D and Font dictionary

[Vincent Hennebert]

Victor Mote a écrit :

I am not sure what you mean "getPDF/PSSubset".


If I'm correct it is only possible to embed the whole font file in a pdf output, 
by using getPDFFontFileStream. Currently aXSL doesn't seem to provide a means to 
embed only a subset.




Point me to the FOP code that does the embedding, class name(s) and line
numbers, and I'll see if I can extract it into an aXSL-exposed method.


The whole code is in the class render.ps.PSFontUtil, mainly the method 
embedType1Font.



3. Still doing this would require hacking the FOrayFont 
subpackage; that would 
result in something dirty but that should work;


Better would be to just make aXSL provide what needs to be provided. If we
can hack FOray to do it, then we should be able to expose what is needed.
Since nothing we are talking about here is a pollution of the interface, we
should just be able to change the interface.


On this point I was more thinking of a quick short-term solution for the 
pre-release, before taking the time to think about a clean implementation.



4. Anyway there are several improvements to bring to the PS 
renderer: mainly 
character encoding, font embedding and in a longer term 
two-pass rendering for a 
proper font handling.


OK. I am confused. I thought above that font embedding worked in PS now, but
this seems to indicate that it does not.


Sorry, it also is a bit unclear to me. I think the precise status is the 
following:
1. font embedding only works with Type1 font for which a pfb file is provided 
(or also a pfa?). Subsetting --provided that this is specified by the postscript 
standard-- does not work;
2. currently only the WinAnsi charset seems to be supported. Fonts are 
systematically reencoded to this charset




I can take some of this burden off of you, in that I can hopefully fix aXSL
and FOray to provide what is needed. If that is done well, you shouldn't
need to learn too much PostScript to get it to work, and perhaps one of the
other developers can help you get it glued in. I don't know how much work it
will take for me to get the FOray PS Renderer working (it may work now), I
can use that as a test bed also.


I appreciate your offer to help! Today I quickly launched the FOray PS Renderer 
but it doesn't seem to work. I haven't investigated, though, this may be a minor 
problem.



Vincent

Re: PSDocumentGraphics2D and Font dictionary

[Vincent Hennebert]

Victor Mote a écrit :

Jeremias Maerki wrote:

output format. Maybe the Font interface should simply have a 
method to return a very generic interface for more detailed 
and font- and output-system-specific access to the font. 
Consumers of this interface can then cast it to a special 
interface/class. Something like:
TargetFormatHelper Font.getTargetFormatHelper(String mime) 
Subclasses of TargetFormatHelper could be 
PDFTargetFormatHelper or a PSTargetFormatHelper. The Font 


This is an interesting idea, but, if I understand it correctly, breaks
pluggability.


aXSL and FOray easily, because I've no direct access to the font 
files;


Which is a problem IMO. See my comments above.


I *really* don't understand this. The whole point of the font subsystem is
to hide as much detail as possible from the client application. If you want
access to the raw font data, then perhaps the FOP 0.20.5 approach is better
for what you need??!!


To go a bit along with Victor, the font subsystem should perhaps provide more 
services, depending on the client (= the type of renderer):

* a font abstraction like it is now for the layout part;
* font manipulation facilities, like e.g. embedding and subsetting for the PDF 
renderer, conversion Type1 -> SVG for the SVG one, etc. In fact I would rather 
put your proposed classes at the font subsystem level.



If aXSL-font provides access to the raw underlying font 
streams, that problem basically dissolves. The following 
would certainly be no

problem:
InputStream Font.getRawStream(String part) where part may be 
"pfb", "pfm", "afm", "ttf" etc.


Is this just for embedding purposes, or do you intend to parse it? If you
want to parse it, why? If all you want to do is embed it, why do you want
the metrics files? FOray essentially provides the raw font stream now. It
works for PDF, but, if I understand Vincent correctly, does not work for PS.
So how does this method you suggest help that?


See just above.



Integrating FOrayFont in the pre-release would be great...


Quite unrealistic as it stands now, sorry.


That is your (FOP's) decision, but it makes no sense to me. You are willing
to go backwards in almost any other area, but are unwilling to *not* go
forwards with PostScript font embedding? Even when it is doable?

Still, I appreciate knowing. I'll shift my focus back to getting my FOray
release out the door.


Victor, from a non-native speaker POV you seem to be a bit overreacting here. I 
have the feeling that I have misled you because of my bad understanding of the 
problem. I'm sorry if this is the case.
Jeremias has a better vision of the situation than me, and I quite agree with 
him that the integration won't be ready for the pre-release. This does not mean 
that it will never be done. And after all, all the better: we will have more 
time to discuss about a clean API.


Regards,
Vincent

P.S.: that said, the PDFRenderer should now work fine with the new font system; 
converting the SVG library should be pretty easy; this basically works for the 
AWT viewer. Nothing perfect, but... ;-)

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Vincent Hennebert wrote:

> > I am not sure what you mean "getPDF/PSSubset".
> 
> If I'm correct it is only possible to embed the whole font 
> file in a pdf output, by using getPDFFontFileStream. 
> Currently aXSL doesn't seem to provide a means to embed only a subset.

OK. I understand. Yes, subsetting only works for TrueType fonts. I built a
rudimentary PostScript interpreter that is currently only used for parsing
some of the metrics out of PFA/PFB files, but which should eventually be
able to help us subset Type 1 fonts.

> > Point me to the FOP code that does the embedding, class name(s) and 
> > line numbers, and I'll see if I can extract it into an 
> aXSL-exposed method.
> 
> The whole code is in the class render.ps.PSFontUtil, mainly 
> the method embedType1Font.

Thanks, I'll work on that.

> Sorry, it also is a bit unclear to me. I think the precise 
> status is the following:
> 1. font embedding only works with Type1 font for which a pfb 
> file is provided 
> (or also a pfa?). Subsetting --provided that this is 
> specified by the postscript 
> standard-- does not work;
> 2. currently only the WinAnsi charset seems to be supported. 
> Fonts are 
> systematically reencoded to this charset

OK, that is consistent with what Jeremias said. I understand where FOP is
now.

> > I can take some of this burden off of you, in that I can 
> hopefully fix aXSL
> > and FOray to provide what is needed. If that is done well, 
> you shouldn't
> > need to learn too much PostScript to get it to work, and 
> perhaps one of the
> > other developers can help you get it glued in. I don't know 
> how much work it
> > will take for me to get the FOray PS Renderer working (it 
> may work now), I
> > can use that as a test bed also.
> 
> I appreciate your offer to help! Today I quickly launched the 
> FOray PS Renderer 
> but it doesn't seem to work. I haven't investigated, though, 
> this may be a minor 
> problem.

I think you may have the honor of being the first person to ever use it :-)
I'll see if I can get it working at some basic level.

Victor Mote

RE: PSDocumentGraphics2D and Font dictionary

[Victor Mote]

Vincent Hennebert wrote:

> >>>Integrating FOrayFont in the pre-release would be great...
> >>
> >>Quite unrealistic as it stands now, sorry.
> > 
> > That is your (FOP's) decision, but it makes no sense to me. You are 
> > willing to go backwards in almost any other area, but are 
> unwilling to 
> > *not* go forwards with PostScript font embedding? Even when 
> it is doable?
> > 
> > Still, I appreciate knowing. I'll shift my focus back to getting my 
> > FOray release out the door.
> 
> Victor, from a non-native speaker POV you seem to be a bit 
> overreacting here. I have the feeling that I have misled you 
> because of my bad understanding of the problem. I'm sorry if 
> this is the case.
> Jeremias has a better vision of the situation than me, and I 
> quite agree with him that the integration won't be ready for 
> the pre-release. This does not mean that it will never be 
> done. And after all, all the better: we will have more time 
> to discuss about a clean API.

You didn't mislead me at all, nor did you do anything else wrong. On the
contrary, I appreciate your efforts greatly.

WRT me overreacting, perhaps I have been misunderstood. The font system
works well enough for what FOray needs ATM, but there are a lot of other
things that don't. I have rearranged my priorities to try to make sure that
I am not a bottleneck on any of this for FOP. I guess this made it higher on
my priority list than it was on FOP's, which is pretty stupid. So, having
now a better understanding of where everyone else's priorities are, I am
glad for the opportunity to adjust mine back to where they really ought to
be anyway: FOray.

> P.S.: that said, the PDFRenderer should now work fine with 
> the new font system; converting the SVG library should be 
> pretty easy; this basically works for the AWT viewer. Nothing 
> perfect, but... ;-)

That is good news, and I think you should be applauded for your efforts
here.

Victor Mote

FOray contacts

[Victor Mote]

FOP devs:

I think it is prudent for me to take this temporary lull to extricate myself
a bit more by unsubscribing from the fop-dev mailing list. I have tried to
do this several times before, with little success, as you can see. I have no
projects underway and no feuds to tend to ATM, so it is a rare (unique
really) opportunity.

I hope no one will misinterpret the timing or motivation. I am not mad at
anyone. On the contrary I feel at peace with everyone still active. I do
think my time and yours will be better spent without me being involved here.
There are legitimate things that need to be discussed between our two
projects, but those are really FOray issues, not FOP issues, so it will
clean things up a bit to get those conversations moved to a more appropriate
forum. Vincent is already active on the foray-developer mailing list, and
all other interested parties are welcome as well. Links to the various FOray
mailing lists can be found on these pages:
http://www.foray.org/app/using/start.html
http://www.foray.org/dev/index.html

If replies are made to recent posts that require a response from me, please
just cc: me in them. I'll resubscribe temporarily if I need to.

I congratulate all of you on your upcoming release, and wish you all the
best.

Victor Mote

Re: FOray contacts

[Manuel Mall]

Victor,

On Wed, 14 Sep 2005 09:07 am, Victor Mote wrote:
> FOP devs:
>
> I think it is prudent for me to take this temporary lull to extricate
> myself a bit more by unsubscribing from the fop-dev mailing list. I
> have tried to do this several times before, with little success, as
> you can see. I have no projects underway and no feuds to tend to ATM,
> so it is a rare (unique really) opportunity.

personally I believe anyone who has worked on fop and has an active 
interest in XSL-FO can still make valuable contributions here. 

Even if you don't want to get involved in (further) design discussion 
based on events in the past I believe you still have lots to 
contribute. For example at the level of input to issues with the spec 
itself and its interpretation because of your extensive knowledge in 
that area. 

Therefore I am very sorry to see you leave this list.

>
> Victor Mote

Regards

Manuel

Re: fo:inline bpd

[Manuel Mall]

On Wed, 14 Sep 2005 01:33 am, Finn Bock wrote:
> [Manuel]
>
> > Any way, back to the topic at hand. Lets assume the following fo:
> >
> > some 10pt text > font-size="12pt">some 12 pt textmore 10pt
> > text
> >
> > In this case the line-height everywhere is normal which is
> > equivalent to 1.2em. The innermost fo:inline will return an area
> > with a bpd of 12pt. However, the outer fo:inline has a smaller font
> > and as the line-height spec on an inline element is binding it can
> > only return areas of 10pt bpd therefore "cutting off" part of the
> > inner fo:inline. So our area tree (assuming it all fits on one
> > line) in fop terminology would look like:
> >
> > 
> >   
> > some 10pt text
> > 
> >   some 12pt text
> > 
> > more 10pt text
> >   
> > 
>
> Right, except the 1 and 12000 values should be text-altitude +
> text-depth:
>
Yes, of course - minor simplification on my part :-).

> 
>
>  some 10pt text
>  
>some 12pt text
>  
>  more 10pt text
>
> 
>
> All the inline areas also have a line-height trait of 12000 but that
> is only used when lls="line-height" [4.6].

Hmm, the line-height property would be "normal" everywhere which equates 
to "1.2" that means the trait would be "14400" for areas generated from 
fo elements with a font-size of "12pt" and "12000" for areas generated 
from fo elements with a font-size of "10pt". But as you said it doesn't 
matter really unless lss is "line-height".

>
> > In my interpretation as there is no explicit line-height spec on
> > the inlines we get an area tree like:
> >
> > 
> >   
> > some 10pt text
> > 
> >   some 12pt text
> > 
> > more 10pt text
> >   
> > 
> >
> > I have no idea whose right or wrong here or even which
> > interpretation makes more sense.
>
>  From [4.6]:
> """An inline-area with inline-area children has a content-rectangle
> which extends from its dominant baseline (see [4.2.6 Font Baseline
> Tables]) by its text-depth in the block-progression-direction, and in
> the opposite direction by its text-altitude;"""
>
> So it appears that the bpd of an inline depends on the inline's font
> and not on the line-height property or the inline's children.
>
> Does it make sense?
>
Yes it does. Does it also means the bpd doesn't "bubble up" in the case 
of nested inlines? So if we expand on the example of the nested inline 
above:

some 10pt textsome 14 pt textmore 10pt
text

Does the line-area generated from that have a bpd corresponding to a 
12pt font or 14 pt font (spec [4.5] for lss="max-height": 
"block-progression-direction is the minimum required to enclose both 
the nominal-requested-line-rectangle and the allocation-rectangles of 
all the inline-areas stacked within the line-area")?

The nominal-requested-line-rectangle corresponds to a 12pt font. But is 
the area generated from the nested inline an "inline-area stacked 
within the line-area" or not? Or is only the inline area generated from 
the outer inline an "inline-area stacked within the line-area" as the 
inner inline area is contained within the outer inline area and 
therefore not really stacked. If the second interpretation is correct 
the line-area would have a bpd corresponding to a 12pt font and only 
unnesting like:

some 10pt 
textsome 14 pt textmore 10pt
text

would give us a line-area with a bpd corresponding to a 14pt font.

>
> I have no idea what the spec means by [7.15.4]:
>
> """If the property is set on an inline-level element, it specifies
> the exact height of each box generated by the element."""
>
> because both "set" and "box" is undefined by the rest of the spec.
> The text is copied from CSS where it perhaps makes sense.
>

OK, I agree its hard to make sense out of this. So lets just ignore this 
then for the time being.

> regards,
> finn

Cheers

Manuel