Bernhard Roider wrote:
>> Yes. We need to convert all file tools to docstring. The only reason why
>> it has not happened so far is that we need the string versions in some
>> parts of the code that cannot be changed to docstring because of regexes
>> (some bibtex stuff).
>>
>
> Is it really nee
Yes. We need to convert all file tools to docstring. The only reason why it
has not happened so far is that we need the string versions in some parts
of the code that cannot be changed to docstring because of regexes (some
bibtex stuff).
Is it really needed to search the bibtex entries with r
Andre Poenitz wrote:
On Tue, Mar 27, 2007 at 10:23:06AM +0200, Abdelrazak Younes wrote:
JMarc, Jose, if Lars has disappeared again I strongly suggest to give
this guy SVN access.
Andel.
What's that? Stick to your side!
Abdre'
:-)
On Tue, Mar 27, 2007 at 10:23:06AM +0200, Abdelrazak Younes wrote:
> JMarc, Jose, if Lars has disappeared again I strongly suggest to give
> this guy SVN access.
>
> Andel.
What's that? Stick to your side!
Abdre'
Michael Gerz wrote:
Bernhard Roider schrieb:
In makeRelPath(..) for every umlaut in abspath or basepath there are
two characters in the
std::string. For determining the matching length of the two strings
(using os::common_path()) they
are converted to docstrings. Converting the strings to docst
Michael Gerz wrote:
> Bernhard Roider schrieb:
>> In makeRelPath(..) for every umlaut in abspath or basepath there are
>> two characters in the
>> std::string. For determining the matching length of the two strings
>> (using os::common_path()) they
>> are converted to docstrings. Converting the st
Bernhard Roider schrieb:
In makeRelPath(..) for every umlaut in abspath or basepath there are
two characters in the
std::string. For determining the matching length of the two strings
(using os::common_path()) they
are converted to docstrings. Converting the strings to docstrings with
from_utf8
It seems that gmane lost my mail, so i send it again
Georg Baum wrote:
Am Montag, 26. März 2007 21:06 schrieb Michael Gerz:
Hello,
again, I am facing a Windows path problem:
If you include a graphics, which is placed in a directory with German
umlauts, the graphics file name get corrupted. T
Georg Baum wrote:
Am Montag, 26. März 2007 21:06 schrieb Michael Gerz:
Hello,
again, I am facing a Windows path problem:
If you include a graphics, which is placed in a directory with German
umlauts, the graphics file name get corrupted. This also happens if the
relative path is umlaut-free.
Michael Gerz schrieb:
Something very bad is going on in makeRelPath:
// Make relative path out of two absolute paths
string const makeRelPath(string const & abspath, string const &
basepath)
// Makes relative path out of absolute path. If it is deeper than
basepath,
// it's
Michael Gerz schrieb:
If you include a graphics, which is placed in a directory with German
umlauts, the graphics file name get corrupted. This also happens if
the relative path is umlaut-free.
I think we should fix this bug before beta 2, because it corrupts your
documents silently.
Someth
Am Montag, 26. März 2007 21:06 schrieb Michael Gerz:
> Hello,
>
> again, I am facing a Windows path problem:
>
> If you include a graphics, which is placed in a directory with German
> umlauts, the graphics file name get corrupted. This also happens if the
> relative path is umlaut-free.
>
> E
Hello,
again, I am facing a Windows path problem:
If you include a graphics, which is placed in a directory with German
umlauts, the graphics file name get corrupted. This also happens if the
relative path is umlaut-free.
Example: Your LyX doc is located in
/c/Documents and Settings/itsy
13 matches
Mail list logo
