Hi,

2016-01-19 17:50 GMT+01:00  <[email protected]>:
> Thanks for the pointer! That was what I was looking for.
>
> So it seems that the config file MUST reside WITH the FO file, in the same
> directory. But only IF base is used in the config file?

No, the config file can be put in any location you want.
You just have to indicate its URI.

> If the base parameter is not used in the config, every relative URI is
> relative to the FO file's location? Do I understand that correctly?

Yes

> In a message dated 1/19/2016 1:31:20 A.M. Pacific Standard Time,
> [email protected] writes:
>
> Hi,
> there is a big change between FOP 1.x and FOP 2.x regarding the base:
> 1.x: base defaults to FOP uri
> 2.x: base defaults to FO uri
>
> See https://issues.apache.org/jira/browse/FOP-2306
>
> 2016-01-19 1:21 GMT+01:00  <[email protected]>:
>> All,
>> Thanks to Tosten who made me think hard ;-)
>>
>> It turns that the FOP config file parameter <base> is the issue. Like
>> Torsten mentioned, the base parameter appears to be an absolute path now
>> in
>> FOP 2.1. However, this is not a good option for an existing system that
>> supports many projects and various paths. My base was set as:
>> <base>./</base>
>>
>> When I set it to an absolute path for testing, FOP 2.1 found all of the
>> files. However, when I REMOVED it, allowing to go to it's default setting
>> (current directory), everything ran normally and files were located
>> correctly.
>>
>> So for my situation, removing the <base> parameter works on FOP 2.1, and
>> it
>> also works on FOP 1.1. I do believe that there is a bug in that section of
>> the 2.1 code.
>>
>> Thanks to everyone that helped out!
>>
>> Regards,
>> Dean Nelson
>>
>> In a message dated 1/18/2016 8:16:34 A.M. Pacific Standard Time,
>> [email protected] writes:
>>
>> Dean,
>>
>> yes, I did this in our docbook xsl configuration layer via changing
>> admin.graphics.path. You may also want to set img.src.path.
>>
>> Hope this helps,
>>
>> Torsten
>>
>>
>> On 18.01.2016 17:04, [email protected] wrote:
>>> Torsten
>>> Did you do this via XSL? Or could you describe how you did this?
>>> Thanks
>>> Dean
>>> In a message dated 1/18/2016 6:12:37 A.M. Pacific Standard Time,
>>> [email protected] writes:
>>>
>>>     Hi Dean,
>>>
>>>     I made the same experience recently, attempting a similar port from
>>> Fop
>>>     1.1 to Fop 2.1 of our DocBook documents.
>>>
>>>     Apparently, Fop 2.1 seems to be more strict about the format of the
>>> url
>>>     argument. I managed to resolve this by converting image references to
>>>     absolute file URIs (e.g. file:///<path>/images/). I was not able to
>>> use
>>>     a relative path and folded.
>>>
>>>     Luckily, in my case mostly admonition graphics were affected, which I
>>>     could resolve by specifying an absolute admon.graphics.path.
>>>
>>>     Hope this helps,
>>>
>>>     Torsten
>>>
>>>     On 17.01.2016 02:29, [email protected] wrote:
>>>      > Hello!
>>>      > Thanks for everyone's hard work on the FOP 2.1 release!
>>>      > I have a stable Docbook system with FOP 1.1 and when I upgraded
>>>     to 2.1 I
>>>      > noticed an issue: It appears that FOP cannot find the images in
>>>     the new
>>>      > system.
>>>      > [ERROR] FOUserAgent - Image not found. URI: images/redneck9.bmp.
>>> (See
>>>      > position 15:562)
>>>      > Which points to this line:
>>>      > <fo:external-graphic src="url(images/redneck9.bmp)" width="7cm"
>>>      > height="auto" content-width="scale-to-fit"
>>>     content-height="scale-to-fit"
>>>      > content-type="content-type:image/BMP" text-align="center"/>
>>>      > This is exactly the same file that FOP 1.1 processes just fine and
>>> I
>>>      > looked to see if there were any changes in the way I needed to
>>>     run FOP
>>>      > but I could not see anything related to that.
>>>      > Was there a change for FOP 2.1 that would cause this?
>>>      > Thanks
>>>      > Dean Nelson


-- 
pascal

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to