[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,
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
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36533.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36533.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36533.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36533.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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
[Manuel]
Any way, back to the topic at hand. Lets assume the following fo:
fo:blockfo:inline font-size=10ptsome 10pt textfo:inline
font-size=12ptsome 12 pt text/fo:inlinemore 10pt
text/fo:inline/fo:block
In this case the line-height everywhere is normal which is equivalent to
1.2em. The
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
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=280608view=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
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
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
[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
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
On 13.09.2005 21:47:01 Victor Mote wrote:
snip/
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
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,
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
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
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
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
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
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
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
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
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:
fo:blockfo:inline font-size=10ptsome 10pt textfo:inline
font-size=12ptsome 12 pt text/fo:inlinemore 10pt
text/fo:inline/fo:block
In this case the line-height
28 matches
Mail list logo
