DO NOT REPLY [Bug 33729] New: - basic-link external-destination (.pdf#dest=) only open pdf file not destination
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33729. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33729 Summary: basic-link external-destination (.pdf#dest=) only open pdf file not destination Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: pdf renderer AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] If I have this: fo:basic-link external-destination=url(destdoc.pdf#dest=destlinkend)some text/fo:basic-link and when I click to link some text then is open pdf file at first page not on page where is destlinkend. In destdoc.pdf basic-link internal-destination work OK: fo:basic-link internal-destination=destlinkendsome text/fo:basic-link -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33738] New: - external-graphic worked until v20.1a to PCL render, now fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33738. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33738 Summary: external-graphic worked until v20.1a to PCL render, now fails Product: Fop Version: 0.20.5 Platform: All OS/Version: Linux Status: NEW Keywords: XSLTBug Severity: major Priority: P3 Component: images AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] I have seen this reported on ticket #33164, but thought (since this is a work-stoppage for me) I would add some more information and re-open this hot item. I cannot upgrade to anything past v20.1a because, after that point, the PCL render output fails when you specify external-graphic in the xsl with a ArrayIndexOutOfBounds error. This worked perfectly with all versions upto 20.1a and before after which point the above error occurs. I have tried every distribution version of fop since to track down the exact point this problem started and what I state is it. This is not a problem with a limited renderring engine as the response to #33164 states as it did work fine before with the same monochrome jpg images. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
--- Jeremias Maerki [EMAIL PROTECTED] wrote: 2. Empty table-bodies make no sense but it makes life easier for stylesheet writers not to have to work around them. I don't see the benefits. In XSLT, one does a test to see if there is data in the source XML that would constitute a fo:table-row. If so, then you activate a template that creates the fo:table. Next, within the template that creates the fo:table (and assorted other fo's including the fo:table-body), you call another template for each fo:table-row. This is standard XSLT programming -- an empty fo:table-body wouldn't be needed, and doesn't appear to be useful for the developer. If there aren't any to-be fo:table-rows in the input XML, the template that creates the fo:table is never called, and so there is no empty fo:table-body necessary. Glen
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
--- Jeremias Maerki [EMAIL PROTECTED] wrote: I have nothing more to say about this. I want to spend my time on more productive things now. Jeremias, I'm going to veto (-1) your change. I would like the content model restored to the XSL standard and the FONode.removeNode() method removed. Technical reasons: 1.) Your content model change is not in agreement with either the 1.0 or 1.1 spec. You did not make a request to the W3C recommending that they make the change to the specification. Our responsibility is to implement the standard, if we need to diverge from it we need to inform them first. I already explained to you[1], via fo:wrapper and fo:page-sequence-wrapper, that they already make allowances in order to ease coding. (Even though I may not like those changes personally.) We are not like a commercial product where we can just ignore the content models, we have a charter and a community responsibility to fulfill. 2.) You failed to explain how an empty fo:table-body could possibly be of use to stylesheet writers, or how it would simplify their work. I was able to debunk what you wrote in my response[2]. All you did say was that it is illegal and not useful, basically strengthening my argument. 3.) As I explained to you, due to the new relationship between FO's and LM's, our architecture no longer supports FO's deciding whether or not to be attached to a LM. I gave you the opportunity to discuss moving back to the older architecture, but you chose to ignore it--instead challenging me to find a better way. That was my question: do we need to move back to the old method? 4.) The change involved would leave vague of how to implement a table header if there is no table-body, worse, it would lead to abuse of the fo:table to just have headers printed. None of this is backed up by the spec--we would be in fantasyland on how to interpret fo:tables without fo:table-bodies. 5.) You're relying a dubious distinction of strict vs. relaxed validation, which has no basis in the spec. The content models for the FO's form the contract of the language that the XSL processor is to accept. Not validating at the source requires more repeated checking downstream, clogging the logic in those places, and creating far more sources of error. All this for an item that you yourself say is of no practical use? 6.) Adhering to the XSL model makes the Apache FOP process the gold standard of validators--an XSL file is not legitimate unless FOP accepts it. Painting FOP as a reference implementation will do wonders for us, just as it has for Tomcat. I *will* support divergences from it, but we have to (1) discuss it beforehand, (2) there has to be a legitimate reason for it--not just saving someone a five-line XSLT template that should be properly written anyway--(3) and explain to the W3C our suggestion first. 7.) I already implemented the official validation. You cannot remove it and then tell me if I want it I have to reimplement it again in a different manner. The burden is on you for that. Our validation unit has to be able to support the spec. Jeremias, I gave you a full, thorough, and respectfully written explanation of the issues involved. Not only did you mostly ignore it, but in your response you chose to use my earlier smaller email in order to give others the impression that I had nothing more to say. This is terrible leadership on your part--railroading a change without discussion and refusal to discuss the change afterwords. I simply can't support this behavior, hence my veto. BTW, letting yourself be known to the W3C by writing to them on occasion would appear to be a smart move for you--I don't know why you are fighting this. Glen [1] http://marc.theaimsgroup.com/?l=fop-devm=110922603225376w=2 [2] http://marc.theaimsgroup.com/?l=fop-devm=110930040205336w=2
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java
On 25.02.2005 07:21:25 Glen Mazza wrote: snip/ For the moment I'm not going to answer the veto itself. Your veto makes this situation a one against one. I have presented my reasons for the change and therefore, I request feedback from the rest of the committers on this matter even if it's just a short message. Jeremias, I gave you a full, thorough, and respectfully written explanation of the issues involved. Not only did you mostly ignore it, but in your response you chose to use my earlier smaller email in order to give others the impression that I had nothing more to say. This is terrible leadership on your part--railroading a change without discussion and refusal to discuss the change afterwords. I simply can't support this behavior, hence my veto. It may well be that I'm overreacting here. If that is so, then I'd like an honest feedback from additional members in the team. You must see that with your history I learned to treat your vetoes with caution because of the many times you changed a -1 to a +1 later after a long discussion and a lot of power spent. There's tension between us two and that's bad. ATM I don't know how to resolve it. I tried to be as open as possible and to address any concerns you have. You have repeatedly brought very good points and for that I'm glad but you had to withdraw several vetoes after starting to realize that you were wrong and I've also seen behaviour from your part that I don't like. For example, starting sentences with Mein Freund, bla bla and then later accusing someone else in a different thread of being disrespectful. I didn't say anything about it then. (Also, apologies to Renaud for not speaking up. I didn't want to pour any oil into the fire at that time.) I tried to overlook that, but I have my limits. I sometimes wonder if you're not more of a blocker in this project than a pusher. I don't think I'm the only one thinking like this. You know what happend during the creation of the XML Graphics PMC. BTW, letting yourself be known to the W3C by writing to them on occasion would appear to be a smart move for you--I don't know why you are fighting this. I'm not fighting this. I've had no compelling reason and spare time to do this, yet. The current issue is no reason for me to write anything to the WG. Jeremias Maerki
