Re: [dev] relative hyperlinks become absolute when document is saved
Andreas Harnack wrote: Hi, It seems impossible in OpenOffice to assign a relative URL to a hypertext link; the link is transformed into an absolute URL while saving or loading the document. I came across the problem while working on a little project that uses OpenOffice Basic macros which try to read the hyperlink URL from a text portion. I expected to get the URL as I typed it into the input formed but I did not. To reproduce the problem - create a new empty Writer document, - insert a hypertext link (Insert Hyperlink from the menu bar or Hyperlink from the Toolbar) - enter as target a relative URL starting with the current directory (like ./file.txt), - Apply and Close the dialogue, - open the Navigator and check the target URL of the link just created, it should be as entered, - save and close the file (any name will do) - reopen the file, open the Navigator and check the URL of the link you entered above: The URL as changed to something like file://C://file.txt The same absolute URL is seen in from within a macro. The 'Save URLs relative to' 'File system' and 'Internet' options have both been set. I'm currently using 2.4 under Windows XP and 2.3 under Suse 10.3 but previous versions showed the same behaviour. There are several issues reporting similar behaviour in other circumstances: - 56629 (also duplicate 61484) for exporting documents to PDF - 31267 for exporting Writer documents to .doc format - 22050 and 22107 for saving hyperlinks in spreadsheets A slightly different yet probably related issues might be 43369 (also duplicates 68250, 80560) for importing .doc file in Writer. Issue 56629 is reported to be fixed by a new feature in 2.4, issues 31267 and 43369 are still open. To me it looks like all these issues are related. My guess is, that at some point while storing and/or loading a document any hyperlink URL is transformed to be absolute one, thereby losing the information, how it originally has been entered by the user. Instead, OpenOffice controls the format of a URL by several options. Now finally my questions: Does anybody know whether my assumptions are correct? Assuming they are, why is done the way it is? I think your assumptions are correct. Historically, OOo has stored URLs as instances of INetURLObject (tools/urlobj.hxx), which only supports absolute URLs (there are various functions that take textual input, but ultimately they all result in an absolute INetURLObject). No clear idea why it was originally done that way, though. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Problems with system vs. OOo libstdc++.so.6 mismatch on Linux
http://www.openoffice.org/issues/show_bug.cgi?id=86389 still waits for a fix, rather urgently: On Linux, (at least Sun-built) OOo (and derivatives, like BrOffice) brings along a (rather old) libstdc++.so.6. It can happen that there is a later libstdc++.so.6 already installed on the system, and that certain system libraries that OOo (indirectly) loads depend on this later version, and thus fail to work in OOo. Functionality that is known to be affected is the KDE Look Feel, the KDE configuration backend, and the KDE address book. There appears to be no obvious, general fix for this problem. I would like to initiate a meeting where we can discuss how to proceed, sometime next week. I assume that at least obr and pl (owners of code that loads the problematic system libraries) and hr (for details of what exact version of libstdc++.so.6 we ship) are interested/willing to join the meeting. Depending on who else would want to join --- but be warned that this will become highly technical :) --- I will arrange the meeting as face to face or IRC, so please drop me a line until tomorrow in case you want to join. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Problems with system vs. OOo libstdc++.so.6 mismatch on Linux
Hi, Stephan Bergmann wrote: http://www.openoffice.org/issues/show_bug.cgi?id=86389 still waits for a fix, rather urgently: On Linux, (at least Sun-built) OOo (and derivatives, like BrOffice) brings along a (rather old) libstdc++.so.6. It can happen that there is a later libstdc++.so.6 already installed on the system, and that certain system libraries that OOo (indirectly) loads depend on this later version, and thus fail to work in OOo. Functionality that is known to be affected is the KDE Look Feel, the KDE configuration backend, and the KDE address book. There appears to be no obvious, general fix for this problem. I would Unless I miss somehing - from my POV there is. Just use the normal libstdc++6 from the system and stop shipping standard libs? Any remotely current distro uses libstdc++6. When you build against the old libstdc++6 from gcc 3.4.1 it will work with anything later AFAIK. (Except maybe on the archs you run into the s/double/long double/ change or !i386, but you don't support them anyway). the meeting. Depending on who else would want to join --- but be warned that this will become highly technical :) --- I will arrange the meeting as face to face or IRC, so please drop me a line until tomorrow in case you want to join. I'd like to if it's possible wrt time. Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Getting warning [Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()]
Hi, Am Working on porting OpenOffice onto DirectFB.Have completed the implementation of most of the major functionality. But facing some issues relating document font rendering. Am getting the warning Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() for a regular document text Have used pango to render the font and implemented a PangoFontLayout class deriving from SalLayout in unx under vcl. Following is the code to implement the UTF-16 to UTF-8 conversion where i have found out the problem is arising. m_pLayoutText = new ByteString( rArgs.mpStr, rArgs.mnLength); m_pLayoutText-Convert( RTL_TEXTENCODING_UNICODE, RTL_TEXTENCODING_UTF8 ); pango_layout_set_text( m_pPangoLayout, m_pLayoutText-GetBuffer(), rArgs.mnLength ); For a simple line text properly formatted there is no problem. But Have noticed significant corruption in rendered text when 1)multiple tabs are present infont of a line in the sample doc. 2)Extra spaces are present in the original doc. 3)A space in the form of a grey area is present in the original doc. ...and many more instances not found yet. A removal of the above spaces and tabs removes the warning and the document is rendered cleanly without corruption. Any ideas on the same will be greatle appreciated. :) Regards, Karl -- View this message in context: http://www.nabble.com/Getting-warning--Pango-WARNING-**%3A-Invalid-UTF-8-string-passed-to-pango_layout_set_text%28%29--tp17643055p17643055.html Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Getting warning [Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()]
[EMAIL PROTECTED] wrote: Hi, Am Working on porting OpenOffice onto DirectFB.Have completed the implementation of most of the major functionality. But facing some issues relating document font rendering. Am getting the warning Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() for a regular document text Have used pango to render the font and implemented a PangoFontLayout class deriving from SalLayout in unx under vcl. Following is the code to implement the UTF-16 to UTF-8 conversion where i have found out the problem is arising. m_pLayoutText = new ByteString( rArgs.mpStr, rArgs.mnLength); m_pLayoutText-Convert( RTL_TEXTENCODING_UNICODE, RTL_TEXTENCODING_UTF8 ); pango_layout_set_text( m_pPangoLayout, m_pLayoutText-GetBuffer(), rArgs.mnLength ); What is rArgs in your code snippet? A (class instance wrapping a) char[] that contains UTF-16 (-LE or -BE?) data? What strikes me as odd is that you use rArgs.mnLength in the final call, instead of m_pLayoutText-GetLength(). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Problems with system vs. OOo libstdc++.so.6 mismatch on Linux
Rene Engelhard wrote: Hi, Stephan Bergmann wrote: http://www.openoffice.org/issues/show_bug.cgi?id=86389 still waits for a fix, rather urgently: On Linux, (at least Sun-built) OOo (and derivatives, like BrOffice) brings along a (rather old) libstdc++.so.6. It can happen that there is a later libstdc++.so.6 already installed on the system, and that certain system libraries that OOo (indirectly) loads depend on this later version, and thus fail to work in OOo. Functionality that is known to be affected is the KDE Look Feel, the KDE configuration backend, and the KDE address book. There appears to be no obvious, general fix for this problem. I would Unless I miss somehing - from my POV there is. Just use the normal libstdc++6 from the system and stop shipping standard libs? Any remotely current distro uses libstdc++6. When you build against the old libstdc++6 from gcc 3.4.1 it will work with anything later AFAIK. Thin ice, I fear. Our stated requirements on the runtime environment do not require a libstdc++.so.6 to be available. I have no idea whether/how many systems are out there that would not meet that requirement. Another line of attack I had in mind is to ship a recent version of libstdc++.so.6 (from GCC 4.2, say), even if we continue to build with GCC 3.4.1. The advantages are that it is simple, we do not need to change any code, and OOo keeps running on machines that do not already have a listdc++.so.6 installed (see above); the disadvantage is that it only cures the current symptoms and is no general fix (as in the future system libraries can again have dependencies on then more current versions of libstdc++.so.6). (Except maybe on the archs you run into the s/double/long double/ change or !i386, but you don't support them anyway). the meeting. Depending on who else would want to join --- but be warned that this will become highly technical :) --- I will arrange the meeting as face to face or IRC, so please drop me a line until tomorrow in case you want to join. I'd like to if it's possible wrt time. OK. (As we already started a discussion here, maybe we can change from a meeting to this mailing list, anyway...) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Getting warning [Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()]
Stephan Bergmann wrote: [EMAIL PROTECTED] wrote: Hi, Am Working on porting OpenOffice onto DirectFB.Have completed the implementation of most of the major functionality. But facing some issues relating document font rendering. Am getting the warning Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() for a regular document text Have used pango to render the font and implemented a PangoFontLayout class deriving from SalLayout in unx under vcl. Following is the code to implement the UTF-16 to UTF-8 conversion where i have found out the problem is arising. m_pLayoutText = new ByteString( rArgs.mpStr, rArgs.mnLength); m_pLayoutText-Convert( RTL_TEXTENCODING_UNICODE, RTL_TEXTENCODING_UTF8 ); pango_layout_set_text( m_pPangoLayout, m_pLayoutText-GetBuffer(), rArgs.mnLength ); What is rArgs in your code snippet? A (class instance wrapping a) char[] that contains UTF-16 (-LE or -BE?) data? What strikes me as odd is that you use rArgs.mnLength in the final call, instead of m_pLayoutText-GetLength(). That's ImplLayoutArgs, a helper class in vcl's SalLayout interface which is for text output. The contained string is not necessarily output as a whole but only part of it (e.g. a word out of a paragraph by writer). The contained characters are xub_Unicode (which is effectively sal_Unicode). Kind regards, pl -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Getting warning [Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()]
Philipp Lohmann wrote: Stephan Bergmann wrote: [EMAIL PROTECTED] wrote: Hi, Am Working on porting OpenOffice onto DirectFB.Have completed the implementation of most of the major functionality. But facing some issues relating document font rendering. Am getting the warning Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() for a regular document text Have used pango to render the font and implemented a PangoFontLayout class deriving from SalLayout in unx under vcl. Following is the code to implement the UTF-16 to UTF-8 conversion where i have found out the problem is arising. m_pLayoutText = new ByteString( rArgs.mpStr, rArgs.mnLength); m_pLayoutText-Convert( RTL_TEXTENCODING_UNICODE, RTL_TEXTENCODING_UTF8 ); pango_layout_set_text( m_pPangoLayout, m_pLayoutText-GetBuffer(), rArgs.mnLength ); What is rArgs in your code snippet? A (class instance wrapping a) char[] that contains UTF-16 (-LE or -BE?) data? What strikes me as odd is that you use rArgs.mnLength in the final call, instead of m_pLayoutText-GetLength(). That's ImplLayoutArgs, a helper class in vcl's SalLayout interface which is for text output. The contained string is not necessarily output as a whole but only part of it (e.g. a word out of a paragraph by writer). The contained characters are xub_Unicode (which is effectively sal_Unicode). So a better approach would be to use one of the conversion functions from rtl::OUString to RTL_TEXTENCODING_UTF8 rtl::OString (rtl::OUStringToOString, rtl::OUString::convertToString) and use the resulting rtl::OString's data in the call to pango_layout_set_text. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [discuss] Suggestions for a new Community Council structure
Hi Michael, Original-Nachricht Von: Michael Meeks [EMAIL PROTECTED] So far, apparently my mail didn't hit 'discuss' (moderated ?), and got only a single reply from Cor on the council list. Sorry for not picking up your mail until now. In general I agree, that the election model for the couciul members should change. We have several problems with the current model (problems to find electable candidates who have time to take the work at the council seriously is only one). The council in it's current structure seems very centralistic to me (it's almost built around the project leads). Anyway - it would need time to discuss some rules who should be eligible. An we surely should discuss this. But next council elections are overdue, for more than a year now (if not two). So we really should go on with new elections. I can't believe the astonishing apathy is a ringing endorsement of the existing structure or community, but perhaps a scepticism that anything will ever change and/or that discussion is even worthwhile :-) Hmm ... no. I rather think, the interest in the councils work is rather low within the community. I still think, that the work of the council is not very effective - but this indeed not what the council is thinking. André -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] linux environement fo official Open Office 2.4 builds
Hi, The Sun OOo 2.4 x86 build is done vs. Linux libc-2.2.4 libraries and headers so it will run on practically on every not to old Linux system - the base line system is practically from the stone age. To state the version of every tool used would take pages, suffice to say that we use a patched version of gcc-3.4.1. Heiner Michael Strobel wrote: Hi, Which linux distro is used for the official Open Office 2.4 builds and the exact versions of the tools? The requirements on http://tools.openoffice.org/dev_docs/build_linux.html are a bit vague in some cases. Regards, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Getting warning [Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()]
Stephan Bergmann wrote: Philipp Lohmann wrote: Stephan Bergmann wrote: [EMAIL PROTECTED] wrote: Hi, Am Working on porting OpenOffice onto DirectFB.Have completed the implementation of most of the major functionality. But facing some issues relating document font rendering. Am getting the warning Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() for a regular document text Have used pango to render the font and implemented a PangoFontLayout class deriving from SalLayout in unx under vcl. Following is the code to implement the UTF-16 to UTF-8 conversion where i have found out the problem is arising. m_pLayoutText = new ByteString( rArgs.mpStr, rArgs.mnLength); m_pLayoutText-Convert( RTL_TEXTENCODING_UNICODE, RTL_TEXTENCODING_UTF8 ); pango_layout_set_text( m_pPangoLayout, m_pLayoutText-GetBuffer(), rArgs.mnLength ); What is rArgs in your code snippet? A (class instance wrapping a) char[] that contains UTF-16 (-LE or -BE?) data? What strikes me as odd is that you use rArgs.mnLength in the final call, instead of m_pLayoutText-GetLength(). That's ImplLayoutArgs, a helper class in vcl's SalLayout interface which is for text output. The contained string is not necessarily output as a whole but only part of it (e.g. a word out of a paragraph by writer). The contained characters are xub_Unicode (which is effectively sal_Unicode). So a better approach would be to use one of the conversion functions from rtl::OUString to RTL_TEXTENCODING_UTF8 rtl::OString (rtl::OUStringToOString, rtl::OUString::convertToString) and use the resulting rtl::OString's data in the call to pango_layout_set_text. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Stephan and Phil for your valuable inputs.Yes with the new API it seems to be rendering the lines which previously were being rendered as '?'.However the bullets in the text are still being rendered as ? and if the text contains some spaces marked by grey areas still render as '?' as i had mentioned earlier. Any ideas on it? Thanks again guys for ur suggestions!! :) Regards, Karl -- View this message in context: http://www.nabble.com/Getting-warning--Pango-WARNING-**%3A-Invalid-UTF-8-string-passed-to-pango_layout_set_text%28%29--tp17643055p17649898.html Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: relative hyperlinks become absolute when document is saved
Andreas Harnack schrieb: - create a new empty Writer document, - insert a hypertext link (Insert Hyperlink from the menu bar or Hyperlink from the Toolbar) - enter as target a relative URL starting with the current directory (like ./file.txt), - Apply and Close the dialogue, - open the Navigator and check the target URL of the link just created, it should be as entered, - save and close the file (any name will do) - reopen the file, open the Navigator and check the URL of the link you entered above: The URL as changed to something like file://C://file.txt There is another thing in this context. I tried to check the impact off the Tools Options... Load/Store General Save URLs relative to options. When creating and storing a file as described in the previous post with both options set, then the content.xml in the document.odt file contains a line that reads reads: text:a xlink:type=simple xlink:href=../file.txt./file.txt/text:a . If the test is repeated with both options turn off, the same line reads: text:a xlink:type=simple xlink:href=./file.txt/text:a If the document is opened again, the link is gone (can be checked in the Navigator). That looks definitely like a bug to me. It is reproducible. I used OpenOffice 2.4 on a W2k system. (Perhaps it should be mentioned that ./file.txt doesn't exist) A slightly longer description can be found here: http://user.services.openoffice.org/en/forum/viewtopic.php?f=5t=6358 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
