Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
I do no know much about hyperref, but these hanges look strange to me. Can someone comment? + // since LyX uses unicode, also set the PDF strings to unicode strings with the + // hyperref option unicode + opt += unicode=true,\n ; What happens when the output is _not_ unicode? What does this option do exactly? + // try to extract author and title from document when none is + // explicitely given + if (title.empty() author.empty()) + opt += pdfusetitle,\n ; Why do this even if the author did not ask for it? Shouldn't it be an additional option? In general, adding options behind the user's back looks bad to me. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
I do no know much about hyperref, but these hanges look strange to me. Can someone comment? look on the yeasterday's thread Changeset 20707. i had exactly the same concerns. + // since LyX uses unicode, also set the PDF strings to unicode strings with the + // hyperref option unicode + opt += unicode=true,\n ; What happens when the output is _not_ unicode? What does this option do exactly? + // try to extract author and title from document when none is + // explicitely given + if (title.empty() author.empty()) + opt += pdfusetitle,\n ; Why do this even if the author did not ask for it? Shouldn't it be an additional option? In general, adding options behind the user's back looks bad to me. +1 pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Pavel Sanda [EMAIL PROTECTED] writes: I do no know much about hyperref, but these hanges look strange to me. Can someone comment? look on the yeasterday's thread Changeset 20707. i had exactly the same concerns. Yes, I saw it too late. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
On Thursday 04 October 2007 08:14:22 Jean-Marc Lasgouttes wrote: Why do this even if the author did not ask for it? Shouldn't it be an additional option? I agree with Jean-Marc here, and I also think that we should set this option to be enabled by default. In general, adding options behind the user's back looks bad to me. +1 JMarc -- José Abílio
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
José Matos wrote: In general, adding options behind the user's back looks bad to me. +2
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
On Thursday 04 October 2007 08:14:22 Jean-Marc Lasgouttes wrote: Why do this even if the author did not ask for it? Shouldn't it be an additional option? I agree with Jean-Marc here, and I also think that we should set this option to be enabled by default. it was my original intention to implemented it as check box implicitly set to true. it also require file format change which i planned to merge with the few leftovers we have in the pdf support. seeing your agreement on this issue, i'll prepare some patch for this later. pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
+ // since LyX uses unicode, also set the PDF strings to unicode strings with the + // hyperref option unicode + opt += unicode=true,\n ; What happens when the output is _not_ unicode? How that? What does this option do exactly? Option pdfencoding The PDF format allows two encodings for bookmarks and entries in the information dictionary: PDFDocEncoding and Unicode as UTF-16BE. Option pdfencoding selects between these encodings: * pdfdoc uses PDFDocEncoding. It uses just one byte per character, but the supported characters are limited (244 in PDF-1.7). * unicode sets Unicode. It is encoded as UTF-16BE. Two bytes are used for most characters, surrogates need four bytes. * auto PDFDocEncoding if the string does not contain characters outside the encoding and Unicode otherwise. iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. And nevertheless, whenever the user uses not latin1 as encoding, unicode must be set to get proper PDF-bookmarks. + // try to extract author and title from document when none is + // explicitely given + if (title.empty() author.empty()) + opt += pdfusetitle,\n ; Why do this even if the author did not ask for it? Shouldn't it be an additional option? In general, adding options behind the user's back looks bad to me. Before people start to add their +1, please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html regards Uwe
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. I hope, because if some trouble bubbles up user has no reasonable way how to get rid of it then. Pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Uwe Stöhr [EMAIL PROTECTED] writes: + // since LyX uses unicode, also set the PDF strings to unicode strings with the + // hyperref option unicode + opt += unicode=true,\n ; What happens when the output is _not_ unicode? How that? So when a document is in, say, latin2, the pdf strings will be in correct unicode? iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. And nevertheless, whenever the user uses not latin1 as encoding, unicode must be set to get proper PDF-bookmarks. So the ask the same thing differently, why isn't it the default then? What are the drawbacks? Before people start to add their +1, please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html I read it, but I still prefer a checkbox, even if it defaults to on. As for the previous option, if it was so great, it would default to true in hyperref. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Jean-Marc Lasgouttes schrieb: So when a document is in, say, latin2, the pdf strings will be in correct unicode? As far as I tested, yes. iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. And nevertheless, whenever the user uses not latin1 as encoding, unicode must be set to get proper PDF-bookmarks. So the ask the same thing differently, why isn't it the default then? What are the drawbacks? This feature doesn't work for all textclasses. That means for some text classes the pdftitle will still be empty, although this option is set and the document has a title environment. To this option means: Try to get the title and aiuthor if possible, if not possible leave it as it is. Before people start to add their +1, please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html I read it, but I still prefer a checkbox, even if it defaults to on. As for the previous option, if it was so great, it would default to true in hyperref. Fine with me. Pavel, do you want to implement this? regards Uwe
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Before people start to add their +1, please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html I read it, but I still prefer a checkbox, even if it defaults to on. As for the previous option, if it was so great, it would default to true in hyperref. Fine with me. Pavel, do you want to implement this? Yes, I will do it next week. Pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
I do no know much about hyperref, but these hanges look strange to me. Can someone comment? > + // since LyX uses unicode, also set the PDF strings to unicode strings > with the > + // hyperref option "unicode" > + opt += "unicode=true,\n "; What happens when the output is _not_ unicode? What does this option do exactly? > + // try to extract author and title from document when none is > + // explicitely given > + if (title.empty() && author.empty()) > + opt += "pdfusetitle,\n "; Why do this even if the author did not ask for it? Shouldn't it be an additional option? In general, adding options behind the user's back looks bad to me. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
> I do no know much about hyperref, but these hanges look strange to me. > Can someone comment? look on the yeasterday's thread Changeset 20707. i had exactly the same concerns. > > + // since LyX uses unicode, also set the PDF strings to unicode strings > > with the > > + // hyperref option "unicode" > > + opt += "unicode=true,\n "; > > What happens when the output is _not_ unicode? What does this option > do exactly? > > > + // try to extract author and title from document when none is > > + // explicitely given > > + if (title.empty() && author.empty()) > > + opt += "pdfusetitle,\n "; > > Why do this even if the author did not ask for it? Shouldn't it be an > additional option? > > In general, adding options behind the user's back looks bad to me. +1 pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Pavel Sanda <[EMAIL PROTECTED]> writes: >> I do no know much about hyperref, but these hanges look strange to me. >> Can someone comment? > > look on the yeasterday's thread Changeset 20707. i had exactly the same > concerns. > Yes, I saw it too late. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
On Thursday 04 October 2007 08:14:22 Jean-Marc Lasgouttes wrote: > Why do this even if the author did not ask for it? Shouldn't it be an > additional option? I agree with Jean-Marc here, and I also think that we should set this option to be enabled by default. > In general, adding options behind the user's back looks bad to me. +1 > JMarc -- José Abílio
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
José Matos wrote: In general, adding options behind the user's back looks bad to me. +2
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
> On Thursday 04 October 2007 08:14:22 Jean-Marc Lasgouttes wrote: > > Why do this even if the author did not ask for it? Shouldn't it be an > > additional option? > > I agree with Jean-Marc here, and I also think that we should set this > option > to be enabled by default. it was my original intention to implemented it as check box implicitly set to true. it also require file format change which i planned to merge with the few leftovers we have in the pdf support. seeing your agreement on this issue, i'll prepare some patch for this later. pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
> > + // since LyX uses unicode, also set the PDF strings to unicode strings >> with the >> + // hyperref option "unicode" >> + opt += "unicode=true,\n "; > > What happens when the output is _not_ unicode? How that? > What does this option do exactly? Option pdfencoding The PDF format allows two encodings for bookmarks and entries in the information dictionary: PDFDocEncoding and Unicode as UTF-16BE. Option "pdfencoding" selects between these encodings: * "pdfdoc" uses PDFDocEncoding. It uses just one byte per character, but the supported characters are limited (244 in PDF-1.7). * "unicode" sets Unicode. It is encoded as UTF-16BE. Two bytes are used for most characters, surrogates need four bytes. * "auto" PDFDocEncoding if the string does not contain characters outside the encoding and Unicode otherwise. iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. And nevertheless, whenever the user uses not latin1 as encoding, unicode must be set to get proper PDF-bookmarks. >> + // try to extract author and title from document when none is >> + // explicitely given >> + if (title.empty() && author.empty()) >> + opt += "pdfusetitle,\n "; > Why do this even if the author did not ask for it? Shouldn't it be an > additional option? In general, adding options behind the user's back looks bad to me. Before people start to add their "+1", please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html regards Uwe
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
> iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. I hope, because if some trouble bubbles up user has no reasonable way how to get rid of it then. Pavel
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Uwe Stöhr <[EMAIL PROTECTED]> writes: >> > + // since LyX uses unicode, also set the PDF strings to unicode >> > strings >>> with the >>> + // hyperref option "unicode" >>> + opt += "unicode=true,\n "; >> >> What happens when the output is _not_ unicode? > > How that? So when a document is in, say, latin2, the pdf strings will be in correct unicode? > iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I > think. And nevertheless, whenever the user uses not latin1 as > encoding, unicode must be set to get proper PDF-bookmarks. So the ask the same thing differently, why isn't it the default then? What are the drawbacks? > Before people start to add their "+1", please read my statement in > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html I read it, but I still prefer a checkbox, even if it defaults to on. As for the previous option, if it was so great, it would default to true in hyperref. JMarc
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
Jean-Marc Lasgouttes schrieb: So when a document is in, say, latin2, the pdf strings will be in correct unicode? As far as I tested, yes. iT IS SAVE TO USE UNICODE IN ALL CASES. I tested this carefully I think. And nevertheless, whenever the user uses not latin1 as encoding, unicode must be set to get proper PDF-bookmarks. So the ask the same thing differently, why isn't it the default then? What are the drawbacks? This feature doesn't work for all textclasses. That means for some text classes the pdftitle will still be empty, although this option is set and the document has a title environment. To this option means: "Try to get the title and aiuthor if possible, if not possible leave it as it is." Before people start to add their "+1", please read my statement in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html I read it, but I still prefer a checkbox, even if it defaults to on. As for the previous option, if it was so great, it would default to true in hyperref. Fine with me. Pavel, do you want to implement this? regards Uwe
Re: [Cvslog] r20707 - /lyx-devel/trunk/src/PDFOptions.cpp
>>> Before people start to add their "+1", please read my statement in >>> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg129100.html >> I read it, but I still prefer a checkbox, even if it defaults to on. >> As for the previous option, if it was so great, it would default to >> true in hyperref. > > Fine with me. Pavel, do you want to implement this? Yes, I will do it next week. Pavel
