Thanks for taking the time to explain Glen. What youve said is mostly as I understood it. Some comments below.
<snip/>
The FOUserAgent is ultra-easy (?) to access from the FOP Application, but not-so-easy (and, also, not-so-relevant) for the PDFTranscoder. (We also have an SVGUserAgent, but I haven't researched it.)
Opportunity for a UserAgent super class? (see below)
<snip/>
Should a method need FOUserAgent--and I couldn't find any in Image *directly* using it (a call to the SVG package did, however, but I don't know if that SVG package also just wanted its logger, I stopped researching to that degree)--well, then, we can't change its signature.
I wouldnt expect you to find any instances of FOUserAgent being used at this time, because AFAIK configuration hasnt yet been implemented in HEAD. I am just trying to make sure that before we delete all references to FOUserAgent from the images package that weve considered whether the images package will need access to configuration when its implemented in HEAD. Presumably such an implementation would start with a basic set of user config settings, and be expanded over time according to user demands.
My inclination is to make FOUserAgent a FOP-only
critter and save the PDFTranscoder from it where
possible. I.e., in the example below of needing an
image baseDir, sending the
foUserAgent.getImageBaseDir() as a parameter instead,
so Thomas can just send "myImageBaseDir" to the same
method for his transcoder work, without needing to
bother with an FOUserAgent.
I dont have any particular interest in this area, I just dont want to undo something that we may need to redo later. If you think its a non issue, then thats fair enough, just as long as its been thought through.
Thanks,
Chris
