From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: Re: odt export bug, I think. Date: Wed, 17 Aug 2011 20:44:35 -0400 Message-ID: References: <81sjozsiqi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=20cf307cfc8cb69a6404aabcea31 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qtqis-0006yv-Ep for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 20:44:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qtqiq-0003Pz-7j for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 20:44:38 -0400 Received: from mail-vx0-f169.google.com ([209.85.220.169]:62264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qtqiq-0003Pu-2N for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 20:44:36 -0400 Received: by vxj3 with SMTP id 3so1576714vxj.0 for ; Wed, 17 Aug 2011 17:44:35 -0700 (PDT) In-Reply-To: <81sjozsiqi.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Jambunathan K Cc: Org Mode --20cf307cfc8cb69a6404aabcea31 Content-Type: multipart/alternative; boundary=20cf307cfc8cb69a6004aabcea2f --20cf307cfc8cb69a6004aabcea2f Content-Type: text/plain; charset=ISO-8859-1 Hi Jambunathan, This is a little hard to do in gmail, which auto-encodes everything! unfortunately wanderlust has been broken for me for some time... I've attached a text file that I think answers all you questions appropriately. Unfortunately my original file file is a year old, so I'm not entirely sure of the answer to question 3 (see below). On Wed, Aug 17, 2011 at 7:47 PM, Jambunathan K wrote: > > Hello Matt > > > Hi, > > > > I think I've found an odt export bug. Certain complex URL's stored > > within links can end up being rendered with forbidden characters, > > e.g. '<' and '>'. so, e.g., a link to this URL: > > > > http://www.jstor.org.myaccess.library.utoronto.ca/sici?origin= > > sfx%253Asfx&sici=1363-3554%25281995%252939%253C182%253E1.0.CO%253B2-L > > & > > > > was rendered in content.xml like this: > > xlink:href="http://www.jstor.org/sici?origin=sfx:sfx&sici= > > 1363-3554(1995)39<182>1.0.CO;2-L&" > > > I have some understanding of what the issue is. I would like to > know/confirm a few things before proceeding ahead: > > 1. How does the original URL look like? > in my browser window, this is the way the link looks (pasted directly): http://www.jstor.org.myaccess.library.utoronto.ca/sici?origin=sfx%25g3Asfx&sici=1363-3554%281995%2939%3C182%3E1.0.CO%3B2-L& in the browser location bar, though, you can see the angle brackets (so, the final segment of the url reads: 1363-3554(1995)39<182>1.0.CO;2-L& ). For reasons I don't understand neither parentheses nor angle brackets can be pasted into emacs or any other editor (this on Ubuntu Maverick, running Gnome 2.something). 2. Where does the URL come from? Is it generated by an application or is > it hand copied by you from your browser. > I'm *pretty* sure I got it using org-capture or (possibly!) org-remember. In those days I used org-protocol to capture links; I don't really do that anymore, though not for any particular reason. > 3. How do you enter the URL in to the org file. Specifically do you > > - Simply type it. ie type the open brackets, paste the link, paste > the description, close the brackets etc. > > Or > > - You use C-c l to store the link in Org file. > > I am fairly certain I used org-protocol to capture the links. but note that the error seems to persist even if I simply cut and paste directly from my browser window. > Note that question 3 is very crucial because. This is because for the > URL that you have provided what you see with C-c l on the link is > different from what is actually stored in the Org file. (You can see > how actually Org stores the link by backspacing from beyond the link > or by toggling descriptive/literal links in the menu bar) > > Please respond to Question 1 keeping behaviour in 3 mind. I am > specifically interested in seeing whether the app/database (if there is > one) actually provides a hexified link or not. I also see the > possibility that one could have handcrafted the URL in an one-off sense > by concatenating key/val pairs and forming the query string oneself. In > this case (a novice) user may not have hexified the URL to begin with. > > ps: If my understanding is correct you are also having similar problems > with the html export (M-x org-export-as-html) as well. Either html file > is malformed or the link in the html export file simply doesn't > work. this is precisely correct. > (TIP: odt exporter is derived from the html exporter. So it is > always a good idea to check the status of html export whenever one runs > in to issues with odt exporter) > thanks for this. > > I anticipate that fix for this issue might need some discussions with > Bastien, David Maus and may be others. > > If the issue originates in the manner in which the initial URL was enteredi nto org/emacs, then this might not be worth too much of everyone's time. I think , in all likelihood, I used an outmoded manner of exchange between org and firefox (using org 6.x!), which even I don't use anymore. And it turns out htere is a simpler, permanent URL for the same resource so even that particular issue no longer matters much for me. If you think it's a significant issue, though, I will certainly do what I can to track it down. thanks again, so much, Matt --20cf307cfc8cb69a6004aabcea2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jambunathan,

This is a little hard to do in gmail, which auto-enc= odes everything! unfortunately wanderlust has been broken for me for some t= ime...

I've attached a text file that I think answers all you qu= estions appropriately.=A0 Unfortunately my original file file is a year old= , so I'm not entirely sure of the answer to question 3 (see below).

On Wed, Aug 17, 2011 at 7:47 PM, Jambunathan= K <kjambuna= than@gmail.com> wrote:

Hello Matt

> Hi,
>
> I think I've found an odt export bug.=A0 Certain complex URL's= stored
> within links can end up being rendered with forbidden characters,
> e.g. '<' and '>'.=A0 so, e.g., a link to this UR= L:
>
> http://www.jstor.org.myaccess.library.utoronto.ca/= sici?origin=3D
> sfx%253Asfx&sici=3D1363-3554%25281995%252939%253C182%253E1.0.CO%253B2-L
> &
>
> was rendered in content.xml like this:
> xlink:href=3D"http://www.jstor.org/sici?origin=3Dsf= x:sfx&amp;sici=3D
> 1363-3554(1995)39<182>1.0.CO;2-L&amp;"


I have some understanding of what the issue is. I would like to
know/confirm a few things before proceeding ahead:

1. How does the original URL look like?
in my browser = window, this is the way the link looks (pasted directly):
http://www.jstor= .org.myaccess.library.utoronto.ca/sici?origin=3Dsfx%25g3Asfx&sici=3D136= 3-3554%281995%2939%3C182%3E1.0.CO%3B2-L&

in the browser location bar, though, you can see the angle brackets (so= , the final segment of the url reads: 1363-3554(1995)39<182>1.0.CO;2-L& ). =A0 For reasons I don't under= stand neither parentheses nor angle brackets can be pasted into emacs or an= y other editor (this on Ubuntu Maverick, running Gnome 2.something).

2. Where does the URL come from? Is it generated by an application or is =A0 it hand copied by you from your browser.
I'm = *pretty* sure I got it using org-capture or (possibly!) org-remember. In th= ose days I used org-protocol to capture links; I don't really do that a= nymore, though not for any particular reason.
3. How do you enter the URL in to the org file. Specifically do you

=A0 - Simply type it. ie type the open brackets, paste the link, paste
=A0 =A0 the description, close =A0the brackets etc.

=A0Or

=A0 - You use C-c l to store the link in Org file.

I am fairly certain I used org-protocol to capture th= e links. but note that the error seems to persist even if I simply cut and = paste directly from my browser window.=A0
=A0
=A0Note that question 3 is very crucial because. This is because for the =A0URL that you have provided what you see with C-c l on the link is
=A0different from what is actually stored in the Org file. (You can see =A0how actually Org stores the link by backspacing from beyond the link =A0or by toggling descriptive/literal links in the menu bar)

Please respond to Question 1 keeping behaviour in 3 mind. I am
specifically interested in seeing whether the app/database (if there is
one) actually provides a hexified link or not. I also see the
possibility that one could have handcrafted the URL in an one-off sense
by concatenating key/val pairs and forming the query string oneself. In
this case (a novice) user may not have hexified the URL to begin with.

ps: If my understanding is correct you are also having similar problems
with the html export (M-x org-export-as-html) as well. Either html file
is malformed or the link in the html export file simply doesn't
work.

this is precisely correct.
=A0
(TIP: odt exporter is der= ived from the html exporter. So it is
always a good idea to check the status of html export whenever one runs
in to issues with odt exporter)

thanks for this. <= br>

I anticipate that fix for this issue might need some discussions with
Bastien, David Maus and may be others.

If the issue originates in the manner in which the in= itial URL was enteredi nto org/emacs, then this might not be worth too much= of everyone's time. I think , in all likelihood, I used an outmoded ma= nner of exchange between org and firefox (using org 6.x!), which even I don= 't use anymore.=A0 And it turns out htere is a simpler, permanent URL f= or the same resource so even that particular issue no longer matters much f= or me. If you think it's a significant issue, though, I will certainly = do what I can to track it down.=A0

thanks again, so much,
Matt
=A0
--20cf307cfc8cb69a6004aabcea2f-- --20cf307cfc8cb69a6404aabcea31 Content-Type: application/octet-stream; name="testingurls.org" Content-Disposition: attachment; filename="testingurls.org" Content-Transfer-Encoding: base64 X-Attachment-Id: f_grh0ckss0 TXkgb3JpZ2luYWwgbGlzdCBpdGVtOgotIE1hc3NleSwgRG9yZWVuLiBbaHR0cDovL3d3dy5qc3Rv ci5vcmcvc2ljaT9vcmlnaW49c2Z4JWczQXNmeCZzaWNpPTEzNjMtMzU1NCUyODE5OTUlMjkzOSUz QzE4MiUzRTEuMC5DTyUzQjItTCZdW1BsYWNlcyBhbmQgVGhlaXIgUGFzdHMuXV0gSGlzdG9yeSBX b3Jrc2hvcCBKb3VybmFsIDM5IChTcHJpbmcgMTk5NSk6IDE4Mi0xOTIKClRoZSB1cmwgYXMgaXQg YXBwZWFycyB3aGVuIHBhc3RlZCBkaXJlY3RseSBmcm9tIG15IGJyb3dzZXI6Cmh0dHA6Ly93d3cu anN0b3Iub3JnL3NpY2k/b3JpZ2luPXNmeCUyNWczQXNmeCZzaWNpPTEzNjMtMzU1NCUyODE5OTUl MjkzOSUzQzE4MiUzRTEuMC5DTyUzQjItTCYKClRoZSBsaXN0IGl0ZW0gYXMgCi0gTWFzc2V5LCBE b3JlZW4uICJbW2h0dHA6Ly93d3cuanN0b3Iub3JnLm15YWNjZXNzLmxpYnJhcnkudXRvcm9udG8u Y2Evc2ljaT9vcmlnaW49c2Z4JTI1ZzNBc2Z4JnNpY2k9MTM2My0zNTU0JTI4MTk5NSUyOTM5JTND MTgyJTNFMS4wLkNPJTNCMi1MJl1bUGxhY2VzIGFuZCBUaGVpciBQYXN0cy5dXSBIaXN0b3J5IFdv cmtzaG9wIEpvdXJuYWwgMzkgKFNwcmluZyAxOTk1KTogMTgyLTE5Mgo= --20cf307cfc8cb69a6404aabcea31--