ove the testing process.
Sorry, but I don't remember (this was in Feb/Mar), except that they
were build errors so I didn't even get around to do the actual
testing. I deciced to walk away from the issue back then to save
myself some time. Next time I won't - promise! :-)
Cheers,
Paul Vinkenoog
, window size
etc.) it can't be shown at the top of the window unless Continuous is
active. Otherwise, the bottom of the page will be aligned with the
bottom of the window and the link target will be "somewhere" on the
visible part of the page.
Kind regards,
Paul Vinkenoog
> +return dest1.getIDRef().compareTo(dest2.getIDRef());
> +}
> +return 0;
Shouldn't the content of the if block be indented?
Kind regards,
Paul Vinkenoog
e it goes wrong, the browsers are at fault,
especially MSIE, and not the destinations code).
Regards,
Paul Vinkenoog
e.org/fop/extensions";
This is not necessary, because fo:bookmarks are part of the standard.
Also, that URL is outdated, iirc.
Hope this helps,
Paul Vinkenoog
only at the
> first page, not at the page where the external link is.
A wild guess: maybe the accent aigu in the id messes up the sorting of
the names. Does the target PDF contain more named destinations? Maybe
you can put it online somewhere (or another one that goes wrong) so
other people can try it out, as well as look inside the PDF.
Kind regards,
Paul Vinkenoog
xisting named destination.)
MSIE made a mess of it right from the start.
In case anybody wants to play with this, the files are at:
http://vinkenoog.nl/test/
The one containing the links is dests.pdf, the target file is
nbackup.pdf
.fo sources are also there, as well as Jay's test files.
Kind regards,
Paul Vinkenoog
ead, it doesn't always work
perfectly. I have no idea what causes those inconsistent results but I
suspect it's on the browser side. Your code and the resulting PDF seem
100% alright.
BTW, I was wrong about the lexicographical ordering. It must be
asciibetical, and that's exactly what you
PS:
> - When I link to those destinations as relative URLs, like this:
>
> external-destination="nbackup.pdf#nbackup-dochist"
>
> then sometimes my browser opens the document on the right spot, and
> sometimes it opens at the top of the file. This is independent of
> the link, i.e. if a
el /Limits are OK: they show the alphabetically first
and last elements.
b) the /Kids are sorted alphabetically on destination name.
So I wonder: might it be the browsers that are screwing up here?
Notice the plural: although Firefox is my default browser, PDF URLs
are opened in MSIE.
Kind regards,
Paul Vinkenoog
tead of a List, and add a compareTo method to
PDFDestination which simply returns the compareTo result on the
respective idRefs.
This will also make sure that the PDFLimit's /Kids are ordered by
destination name (although you don't see those names in the /Kids
array).
Kind regards,
Paul Vinkenoog
tted your destinations code. Sorry, I didn't mean to suggest
that this was your fault.
Kind regards,
Paul Vinkenoog
;on the spot". I'll also hook up the
named destinations to that mechanism.
Kind regards,
Paul Vinkenoog
Hi Pascal,
> I get 11 errors and cannot build this rev.
>
> Latest working rev was 524578 (for me).
It's because DestinationData.java is missing.
Regz,
Paul Vinkenoog
Hello Jay,
> +import org.apache.fop.area.DestinationData;
Did you forget to add DestinationData.java, or is it coming later?
Sorry if I sound impatient - I'm just interested :-)
Kind regards,
Paul Vinkenoog
> last PageSequence.
>
> I don't understand how this can happen,
OK, found it. And it's easily fixed.
Regards,
Paul Vinkenoog
ce.
Should I try to find out what's going on and provide a fix (if
possible), or is this placement as intended?
Kind regards,
Paul Vinkenoog
ion.
So, at the moment, it seems that we can all take our pick depending on
what we prefer. Time for official clarification indeed. Personally I
hope that: a) percentages and explicit lengths should always be
interpreted in the same coordinate system, and b) for absolute and
fixed areas, tha
on by 1000)?
Kind regards,
Paul Vinkenoog
happened to be the last message in the thread, and it triggered my
response because it mentioned the region-reference (and a little
later, the nearest ancestor ref area) as the reference area for fixed
positioning. Sorry about that.
Kind regards,
Paul Vinkenoog
lutely-positioned areas, the visibility may change over
time even if the entire page (or document) is always fully visible,
because one or more of their ancestor reference-areas may be
scrollable within their associated viewport.
All this seems pretty logical and consistent to me, and (AFAIK) within
the specification.
So I hope I'm not just adding to the confusion here... :-)
Yes, I think the spec could have been a lot clearer in places.
Kind regards,
Paul Vinkenoog
reignObject and Image go via renderViewport. Looks like
determining the positions in renderBlock and renderInlineArea is
enough after all.
Anyway, I'll test thoroughly before submitting a patch.
Cheers,
Paul Vinkenoog
intermediate
> format) from those file, you'll see where the prod-id can be set.
>
> [1] you can also just look in build\test-results\layoutengine after
> the build.
Thanks for the tip, I'll have a look at it.
Kind regards,
Paul Vinkenoog
you
people have put in this project. We've been using FOP for years in the
Firebird documentation project and it has become a tremendously
important tool for us. So if there's anything I can do to improve my
current implementation according to your wishes or requirements, I'll
be more than happy to do so -- provided I have the time and the
skills.
Kind regards,
Paul Vinkenoog
24 matches
Mail list logo
