Hi William,
>>>>> "WH" == William Huang <[EMAIL PROTECTED]> writes:
WH> How are you? Thank you very much for your guidance. Here I have
WH> two more questions to ask for your advice.
Sure.
WH> 1. For line spacing, I found that there are some codes for
WH> CSS_LINE_HEIGHT_PROPERTY (line-height) in CSSEngine. Is there a
WH> way to use this property for line spacing functionality? If I need
WH> implement my own line spacing attribute, could you tell me which
WH> program I need to modify and how much the work may be? Is it
WH> possible that X-Smile have some ready for use code since it
WH> supports XHTML?
I don't think X-Smile will be that useful since the tricky bits
are getting the line-height property to behave correctly with Batik's
CSS engine and Glyph Layout code (of course I say this with no
familiarity with XSmiles so I could be totally wrong). I took at
Batik look and it appears that most of the needed functionality is
present already in the CSS Engine. You will need to write a CSS Value
Manager to deal with the relative values (see
org.apache.batik.css.engine.value.svg.BaselineShiftManager).
There is also an issue that currently the SVG spec says that
line-height is always the same as font-size. Obviously we don't want
that here. It appears that BaselineShift is the only value that is
relative to 'line-height' in SVG so you could either make that use
font-size directly (to stay conformant with SVG 1.0) or break the
hardcoded tie of font-size to line-height in the
org.apache.batik.css.engine.SVGCSSEngine:58,88 (I suspect this is the
route the SVG WG will go when FlowText is officially added).
When this is done you should be able to get a correct value for
line-height from the CSS engine. You will then need to add the
LINE_HEIGHT to the attributed string so it can be communicated to the
GlyphLayout class. This should be done in
batik.extension.svg.SVGFlowTextElementBridge probably in the
getAttributeMap method. You might want to look at
batik.bridge.TextUtilities and it's 'convertFontSize' method to get a
good idea of how to do this properly in Batik.
Then finally in org.apache.batik.gvt.text.GlyphLayout there is
already a start at support for lineHeight. But you will need to add
some additional code here to get the lineHeight from the attributed
string as you go along (as any flowSpan may have a different
line-height). This should be modeled on the font stuff already in the
batik.gvt.text.GlyphIterator class.
You need to carefully read the description of line-height in the
CSS2 specification (section 10.8). In particular note that
line-height means different things when specified on a block-level
element (flowPara, flowRegionBreak, flowDiv) then on a inline-level
element (flowSpan, flowLine). Then there is the fairly complex
interplay between the various elements on a line.
As to how much work this is, it's hard for me to estimate it well
for you. I know the code involved very well, and the relevant
specifications reasonably well and I would guess that it is probably
~20-30hr solid work for me say 1 week solid by the time I'm done
writing the tests. I don't know how well you know Java, the relevant
specs (you could easily spend 2 days understanding the relevant bits
of CSS alone, and that assumes you have a basic understanding of fonts
and text layout). I don't mean to scare you off with this, but you
have picked a fairly tricky bit of CSS, but when you were done you
will probably have a much better understanding of these elements
(which if you do a lot with text these days can be extremely useful).
WH> 2. For better 'perceived' performance, I also plan to preload
WH> classes using the Squiggle approach since I also observed the
WH> first SVG file loading introduced much more delay. Since my login
WH> page is a JSP page, I will use a background process to load a
WH> small SVG file when user login. When user subsequently clicks on
WH> the SVG browser link, the class loading time will be reduced. Is
WH> this feasible?
Well reading your description it sounds to me like the preloading
will happen on the server not on the client (The JSP runs on the
server not the client). What you really want to do is set up your
login page to have something like a hidden frame that contains the
applet so the applet is downloaded to the client at the start. Then
once logged in you can make that frame the main frame or something
like this. To be quite honest these sorts of tricks aren't my area of
expertise. But I just want to make sure you aren't pre-loading Batik
on the server where it does no good.
WH> And is it possible for me to customize the browser JVM so that it
WH> can give my Applet more resources just as I use JVM options in
WH> standalone application to control Xms, Xmx and garbage collection
WH> behavior?
There is a control panel for the plugin. Under the 'Advanced' pane
there is a JRE Runtime Parameters which I assume you could use to pass
Xms, Xmx to the JRE plugin.
WH> With best regards, William
I hope this helps. At least it should be pretty good
documentation of what needs to be done even if you decide not to do
it.
WH> -----Original Message----- From: Thomas E Deweese
WH> [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003
WH> 4:34 PM To: Batik Users Subject: RE: How can I use line spacing
WH> with FlowText?
>>>>> "WH" == William Huang <[EMAIL PROTECTED]> writes:
WH> I am using FlowText for better dynamically generated text
WH> support. I have used FlowText to realize most of the
WH> functionalities I need. But I can't figure out how to use the line
WH> spacing functionality. I tried to set dy and line-spacing
WH> attributes for both flowSpan and flowPara, but none of them
WH> works. Could you tell me how to realize this functionality?
WH> Sorry about the mistake I made in my last email. The css attribute
WH> I tried is line-height instead of line-spacing.
WH> Sorry, but this functionality isn't current implemented. As I
WH> recall doing this properly was fairly complex due to the way that
WH> CSS handles computed values etc. I considered putting in a hack
WH> that didn't use CSS (so no cascading) just make it an attribute
WH> but I never did as it wasn't clear that this was particularly
WH> useful.
WH> ---------------------------------------------------------------------
WH> To unsubscribe, e-mail: [EMAIL PROTECTED] For
WH> additional commands, e-mail: [EMAIL PROTECTED]
WH> ---------------------------------------------------------------------
WH> To unsubscribe, e-mail: [EMAIL PROTECTED] For
WH> additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
