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
.
[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
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
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
by 1000)?
Kind regards,
Paul Vinkenoog
and explicit lengths should always be
interpreted in the same coordinate system, and b) for absolute and
fixed areas, that this coordinate system is always the ancestor which
the area is attached to (nearest ancestor-ref and page-vp,
respectively).
Kind regards,
Paul Vinkenoog
to find out what's going on and provide a fix (if
possible), or is this placement as intended?
Kind regards,
Paul Vinkenoog
understand how this can happen,
OK, found it. And it's easily fixed.
Regards,
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
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
regards,
Paul Vinkenoog
, I didn't mean to suggest
that this was your fault.
Kind regards,
Paul Vinkenoog
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
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
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 click
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 your comparator class does.
Greetings,
Paul Vinkenoog
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
.
Kind regards,
Paul Vinkenoog
;
This is not necessary, because fo:bookmarks are part of the standard.
Also, that URL is outdated, iirc.
Hope this helps,
Paul Vinkenoog
are at fault,
especially MSIE, and not the destinations code).
Regards,
Paul Vinkenoog
().compareTo(dest2.getIDRef());
+}
+return 0;
Shouldn't the content of the if block be indented?
Kind regards,
Paul Vinkenoog
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
22 matches
Mail list logo
