On 4/28/2013 2:15 PM, Wolfgang Schuster wrote:
Am 28.04.2013 um 14:08 schrieb Khaled Hosny :
On Sun, Apr 28, 2013 at 12:56:25PM +0200, Hans Hagen wrote:
On 4/28/2013 12:04 PM, Philipp Gesang wrote:
the font cache currently drops non-ascii bytes when creating file
names by means of container
Am 28.04.2013 um 14:08 schrieb Khaled Hosny :
> On Sun, Apr 28, 2013 at 12:56:25PM +0200, Hans Hagen wrote:
>> On 4/28/2013 12:04 PM, Philipp Gesang wrote:
>>
>>> the font cache currently drops non-ascii bytes when creating file
>>> names by means of containers.cleanname(). Dohyun Kim sent a fix
On Sun, Apr 28, 2013 at 12:56:25PM +0200, Hans Hagen wrote:
> On 4/28/2013 12:04 PM, Philipp Gesang wrote:
>
> >the font cache currently drops non-ascii bytes when creating file
> >names by means of containers.cleanname(). Dohyun Kim sent a fix
> >for data-con.lua (see below). My own test with the
ยท
> On 4/28/2013 12:04 PM, Philipp Gesang wrote:
>
> >the font cache currently drops non-ascii bytes when creating file
> >names by means of containers.cleanname(). Dohyun Kim sent a fix
> >for data-con.lua (see below). My own test with the unicode
> >library leads to some odd results.
>
On 4/28/2013 12:04 PM, Philipp Gesang wrote:
the font cache currently drops non-ascii bytes when creating file
names by means of containers.cleanname(). Dohyun Kim sent a fix
for data-con.lua (see below). My own test with the unicode
library leads to some odd results.
strange that it wasn't no
Hi Hans,
the font cache currently drops non-ascii bytes when creating file
names by means of containers.cleanname(). Dohyun Kim sent a fix
for data-con.lua (see below). My own test with the unicode
library leads to some odd results.
Also I noticed that as a pattern, [^%w%d] is a bit redundant
sin