svn commit: r388912 - in /xmlgraphics/batik/trunk/sources/org/apache/batik: bridge/ bridge/svg12/ ex

This change removes
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILI
ES
which FOP's PDFTextPainter relies on. PDFTextPainter uses
that list to
determine if a font is an SVG font and needs to be painted
as shapes
instead of as text. Just FYI. I'll have to find time to
take a closer
look.

On 26.03.2006 16:57:02 deweese wrote:
> Author: deweese
> Date: Sun Mar 26 06:57:00 2006
> New Revision: 388912
> 
> URL: http://svn.apache.org/viewcvs?rev=388912&view=rev
> Log:
> 1) SVG Text no longer forces reference to SVG DOM for
static content,
>    when using AWT fonts.  (SVG Fonts currently still
hold a reference
>    to the SVG Document).
> 
> 2) In most places TEXT_COMPOUND_DELIMITER has
effectively been
>    replaced by TEXT_COMPOUND_ID.  TEXT_COMPOUND_ID has
a unique
>    value for each element in the DOM but retains no
reference to
>    the element.
> 
>    In dynamic documents TEXT_COMPOUND_DELIMITER is
still bound on
>    elements, with a hard reference to the DOM element.
> 
> 
> Modified:
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/SVGT
extElementBridge.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/svg1
2/SVGFlowRootElementBridge.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/extension/s
vg/GlyphIterator.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/flow/Bl
ockInfo.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/font/AW
TFontFamily.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/rendere
r/StrokingTextPainter.java
>    
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/text/GV
TAttributedCharacterIterator.java
<snip/>


Jeremias Maerki


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi Jeremias,

Jeremias Maerki <devjeremias-maerki.ch> wrote on 03/27/2006
01:10:36 AM:

> This change removes 
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILI
ES
> which FOP's PDFTextPainter relies on. 

   Hmm, yes it does.  Sorry about that...

> PDFTextPainter uses that list to determine if a font is
an SVG font and 
> needs to be painted as shapes instead of as text. Just
FYI. I'll have to 

> find time to take a closer look.

   Actually this wouldn't be much of a problem, but it also
uses it to
figure out the name of the font to use in the PDF.  However
this isn't
really the best, it should look at GVT_FONT to see what font
has been
selected for each character/run of chars.  Batik selects the
font based
on it's ability to display the text.

   I've added an interface to GVTFont to get the font
family name.
So eventually FOP can just use the GVT_FONT (or perhaps
GVT_FONTS) to
do this selection (you can test if the GVTFont is an
instance of
batik.bridge.SVGGVTFont like you do for font familes). 

   I can add GVT_FONT_FAMILIES back for now, but it will
have to go 
away eventually since it nessesarily holds a hard ref to the
font's 
DOM (so the font instance can inherit properties from the
text). It is
bad for our GVT tree to hold hard refs to the DOM.

> On 26.03.2006 16:57:02 deweese wrote:
> > Author: deweese
> > Date: Sun Mar 26 06:57:00 2006
> > New Revision: 388912
> > 
> > URL: http://svn.apache.org/viewcvs?rev=388912&view=rev
> > Log:
> > 1) SVG Text no longer forces reference to SVG DOM
for static content,
> >    when using AWT fonts.  (SVG Fonts currently
still hold a reference
> >    to the SVG Document).
> > 
> > 2) In most places TEXT_COMPOUND_DELIMITER has
effectively been
> >    replaced by TEXT_COMPOUND_ID.  TEXT_COMPOUND_ID
has a unique
> >    value for each element in the DOM but retains
no reference to
> >    the element.
> > 
> >    In dynamic documents TEXT_COMPOUND_DELIMITER is
still bound on
> >    elements, with a hard reference to the DOM
element.
> > 
> > 
> > Modified:
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/SVGT
extElementBridge.java
> > 
> 
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/svg1
2/SVGFlowRootElementBridge.
> java
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/extension/s
vg/GlyphIterator.java
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/flow/Bl
ockInfo.java
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/font/AW
TFontFamily.java
> > 
> 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/rendere
r/StrokingTextPainter.java
> > 
> 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/text/GV
TAttributedCharacterIterator.
> java
> <snip/>
> 
> 
> Jeremias Maerki
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Thanks, Thomas. I hope I'll have time during the weekend to
investigate
further. We really need to get the XML Graphics Commons
story forward
somehow. If the PDFTextPainter were in Batik, there would
have been no
problem. As it stands right now, we would pretty much block
our ability
to release FOP until the next Batik release if we follow the
changes in
Batik Trunk. I guess we need to temporarily change the Gump
descriptor
to use the batik.jar in FOP's lib directory. That would at
least allow
you to proceed in the intended direction and you could
remove
GVT_FONT_FAMILIES again.

On 27.03.2006 15:34:44 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <devjeremias-maerki.ch>
wrote on 03/27/2006 01:10:36 AM:
> 
> > This change removes 
>
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILI
ES
> > which FOP's PDFTextPainter relies on. 
> 
>    Hmm, yes it does.  Sorry about that...
> 
> > PDFTextPainter uses that list to determine if a
font is an SVG font and 
> > needs to be painted as shapes instead of as text.
Just FYI. I'll have to 
> 
> > find time to take a closer look.
> 
>    Actually this wouldn't be much of a problem, but it
also uses it to
> figure out the name of the font to use in the PDF. 
However this isn't
> really the best, it should look at GVT_FONT to see what
font has been
> selected for each character/run of chars.  Batik
selects the font based
> on it's ability to display the text.
> 
>    I've added an interface to GVTFont to get the font
family name.
> So eventually FOP can just use the GVT_FONT (or perhaps
GVT_FONTS) to
> do this selection (you can test if the GVTFont is an
instance of
> batik.bridge.SVGGVTFont like you do for font familes). 
> 
>    I can add GVT_FONT_FAMILIES back for now, but it
will have to go 
> away eventually since it nessesarily holds a hard ref
to the font's 
> DOM (so the font instance can inherit properties from
the text). It is
> bad for our GVT tree to hold hard refs to the DOM.
> 
> > On 26.03.2006 16:57:02 deweese wrote:
> > > Author: deweese
> > > Date: Sun Mar 26 06:57:00 2006
> > > New Revision: 388912
> > > 
> > > URL: http://svn.apache.org/viewcvs?rev=388912&view=rev
> > > Log:
> > > 1) SVG Text no longer forces reference to SVG
DOM for static content,
> > >    when using AWT fonts.  (SVG Fonts
currently still hold a reference
> > >    to the SVG Document).
> > > 
> > > 2) In most places TEXT_COMPOUND_DELIMITER has
effectively been
> > >    replaced by TEXT_COMPOUND_ID. 
TEXT_COMPOUND_ID has a unique
> > >    value for each element in the DOM but
retains no reference to
> > >    the element.
> > > 
> > >    In dynamic documents
TEXT_COMPOUND_DELIMITER is still bound on
> > >    elements, with a hard reference to the DOM
element.
> > > 
> > > 
> > > Modified:
> > > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/SVGT
extElementBridge.java
> > > 
> > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/svg1
2/SVGFlowRootElementBridge.
> > java
> > > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/extension/s
vg/GlyphIterator.java
> > > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/flow/Bl
ockInfo.java
> > > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/font/AW
TFontFamily.java
> > > 
> > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/rendere
r/StrokingTextPainter.java
> > > 
> > 
>
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/text/GV
TAttributedCharacterIterator.
> > java
> > <snip/>



Jeremias Maerki


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

Hi Jeremias,

Jeremias Maerki <devjeremias-maerki.ch> wrote on 03/30/2006
02:34:44 AM:

> I hope I'll have time during the weekend to
investigate
> further. We really need to get the XML Graphics Commons
story forward
> somehow. If the PDFTextPainter were in Batik, there
would have been no
> problem. 

   Yup...

> As it stands right now, we would pretty much block our
ability
> to release FOP until the next Batik release if we
follow the changes in
> Batik Trunk. I guess we need to temporarily change the
Gump descriptor
> to use the batik.jar in FOP's lib directory. That
would at least allow
> you to proceed in the intended direction and you could
remove
> GVT_FONT_FAMILIES again.

   I wouldn't worry about this too much.  There is another
fairly large
change that would have to happen to remove the hard refs in
the SVGGVTFont
class.  This is at least possible/practical (removing them
before
deriveFont is called on the FontFamily isn't).  I probably
won't get to
this change for a while so keeping the extra Font Families
attribute
is only a small ugliness for now.

> On 27.03.2006 15:34:44 thomas.deweese wrote:
> > Hi Jeremias,
> > 
> > Jeremias Maerki <devjeremias-maerki.ch>
wrote on 03/27/2006 01:10:36 
AM:
> > 
> > > This change removes 
> >
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILI
ES
> > > which FOP's PDFTextPainter relies on. 
> > 
> >    Hmm, yes it does.  Sorry about that...
> > 
> > > PDFTextPainter uses that list to determine if
a font is an SVG font 
and 
> > > needs to be painted as shapes instead of as
text. Just FYI. I'll 
have to 
> > 
> > > find time to take a closer look.
> > 
> >    Actually this wouldn't be much of a problem,
but it also uses it to
> > figure out the name of the font to use in the PDF.
 However this isn't
> > really the best, it should look at GVT_FONT to see
what font has been
> > selected for each character/run of chars.  Batik
selects the font 
based
> > on it's ability to display the text.
> > 
> >    I've added an interface to GVTFont to get the
font family name.
> > So eventually FOP can just use the GVT_FONT (or
perhaps GVT_FONTS) to
> > do this selection (you can test if the GVTFont is
an instance of
> > batik.bridge.SVGGVTFont like you do for font
familes). 
> > 
> >    I can add GVT_FONT_FAMILIES back for now, but
it will have to go 
> > away eventually since it nessesarily holds a hard
ref to the font's 
> > DOM (so the font instance can inherit properties
from the text). It is
> > bad for our GVT tree to hold hard refs to the DOM.
> > 
> > > On 26.03.2006 16:57:02 deweese wrote:
> > > > Author: deweese
> > > > Date: Sun Mar 26 06:57:00 2006
> > > > New Revision: 388912
> > > > 
> > > > URL: http://svn.apache.org/viewcvs?rev=388912&view=rev
> > > > Log:
> > > > 1) SVG Text no longer forces reference
to SVG DOM for static 
content,
> > > >    when using AWT fonts.  (SVG Fonts
currently still hold a 
reference
> > > >    to the SVG Document).
> > > > 
> > > > 2) In most places
TEXT_COMPOUND_DELIMITER has effectively been
> > > >    replaced by TEXT_COMPOUND_ID. 
TEXT_COMPOUND_ID has a unique
> > > >    value for each element in the DOM but
retains no reference to
> > > >    the element.
> > > > 
> > > >    In dynamic documents
TEXT_COMPOUND_DELIMITER is still bound on
> > > >    elements, with a hard reference to
the DOM element.
> > > > 
> > > > 
> > > > Modified:
> > > > 
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/SVGT
extElementBridge.java
> > > > 
> > > 
> > 
> 
xmlgraphics/batik/trunk/sources/org/apache/batik/bridge/svg1
2/SVGFlowRootElementBridge.
> > > java
> > > > 
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/extension/s
vg/GlyphIterator.java
> > > > 
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/flow/Bl
ockInfo.java
> > > > 
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/font/AW
TFontFamily.java
> > > > 
> > > 
> > 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/rendere
r/StrokingTextPainter.java
> > > > 
> > > 
> > 
> 
xmlgraphics/batik/trunk/sources/org/apache/batik/gvt/text/GV
TAttributedCharacterIterator.
> > > java
> > > <snip/>
> 
> 
> 
> Jeremias Maerki
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org