date:20070110

Pechnikov Alexey - debian-russian@lists.debian.org @ Sat, 6 Jan 2007 12:16:24
+0300:

Черт, как обидн, я всю эту долбаную спецификацию на hal и вдоль и
поперёк прочесал, а в итоге что облом.

PA А коде hal не сделана обработка пользовательской кодировки, идет
PA передача параметра utf8 и все на этом, приехали. Хотя по докам там
PA должны передаваться iocharset codepage. Вообще, если хочется все
PA сделать аккуратно, можно вписать обработку передаваемого параметра
PA с кодировкой и настраивать конфигом, только не вижу смысла,
PA поскольку в официальную ветку этот патч все равно не войдет,
PA придется каждый раз заново вписывать... Такая же ерунда получается
PA с сетевыми ресурсами - конкуерор их пытается отобразить в юникоде,
PA наплевав на кодировку по умолчанию. В итоге получаем еще сырую
PA поддержку юникода и похеренную поддержку однобайтовых кодировок. Не
PA знаю, чего с этим делать, потому что сферы бизнеса позарез нужна
PA cp1251, это стандарт, от которого в ближайшее время не уйти.

Вот уж CP1251 в именах файлов бывает только если ты делаешь бэкап
русифицированного в 1251 пальма средствами pilot-link. Или если
виндузятники к тебе ходят исключительно по ftp. На русских фатовских
дисках короткие имена в 866, длинные - везде в Unicode. При доступе по
самбе - 866, за длинные не поручусь.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Человек - терновый венец природы.
Кнышев

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Вопрос по gcc-4.1

Dmitry Nezhevenko - debian-russian@lists.debian.org  @ Sat, 6 Jan 2007 
02:27:46 +0200:

   DNif(strncmp(secret+1,hash,16) == 0)
   DN на
   DNif(strncmp(secret+1,(char*)hash,16) == 0)
  
   DN Но это вряд ли является причиной проблемы.
  
  Натурально.  Причиной проблемы является то, что используется strncmp
  вместо memcmp.
  

 DN Хм. точно. в hash лежит 16-байтная md5, которая может содержать \0

Что тоже хорошо.  А еще там где-то, кажется, в 16-байтовый буфер
писалась 16-символьная (17-байтовая, сиречь) строка...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает
трудовыми мозолями. (С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kde+hal

В сообщении от Среда 10 января 2007 17:35 Artem Chuprina написал(a):
 Вот уж CP1251 в именах файлов бывает только если ты делаешь бэкап
 русифицированного в 1251 пальма средствами pilot-link.  Или если
 виндузятники к тебе ходят исключительно по ftp.  На русских фатовских
 дисках короткие имена в 866, длинные - везде в Unicode.  При доступе по
 самбе - 866, за длинные не поручусь.
Не только в именах файлов дело - у файлов есть еще и содержимое.

Re: kde+hal

В сообщении от Среда 10 января 2007 19:49 Pechnikov Alexey написал(a):
 На русских фатовских

  дисках короткие имена в 866, длинные - везде в Unicode
Мда? Наверное, мы живем в параллельных мирах.

Re: kde+hal

On Wed, Jan 10, 2007 at 07:51:51PM +0300, Pechnikov Alexey wrote:
 В сообщении от Среда 10 января 2007 19:49 Pechnikov Alexey написал(a):
  На русских фатовских
 
   дисках короткие имена в 866, длинные - везде в Unicode
 Мда? Наверное, мы живем в параллельных мирах.

А где это не так?

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: kde+hal

В сообщении от Среда 10 января 2007 19:58 Dmitry Nezhevenko написал(a):
дисках короткие имена в 866, длинные - везде в Unicode
 
  Мда? Наверное, мы живем в параллельных мирах.

 А где это не так?
Все имена в cp866

Re: kde+hal

On Wed, Jan 10, 2007 at 07:57:11PM +0300, Pechnikov Alexey wrote:
 В сообщении от Среда 10 января 2007 19:58 Dmitry Nezhevenko написал(a):
 дисках короткие имена в 866, длинные - везде в Unicode
  
   Мда? Наверное, мы живем в параллельных мирах.
 
  А где это не так?
 Все имена в cp866

Не верю. венда в юникоде длинные имена пишет. Файловая система точно с -t
vfat монтируется?

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: kde+hal

Pechnikov Alexey - debian-russian@lists.debian.org  @ Wed, 10 Jan 2007 
19:49:10 +0300:

  Вот уж CP1251 в именах файлов бывает только если ты делаешь бэкап
  русифицированного в 1251 пальма средствами pilot-link.  Или если
  виндузятники к тебе ходят исключительно по ftp.  На русских фатовских
  дисках короткие имена в 866, длинные - везде в Unicode.  При доступе по
  самбе - 866, за длинные не поручусь.
 PA Не только в именах файлов дело - у файлов есть еще и содержимое. 

А за кодировку содержимого отвечает уже совершенно другой механизм.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Любой инструмент, используемый не по назначению, имеет свойство
превращаться в грабли.
Andrey Sverdlichenko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kde+hal

В сообщении от Среда 10 января 2007 20:06 Dmitry Nezhevenko написал(a):
 Не верю. венда в юникоде длинные имена пишет. Файловая система точно с -t
 vfat монтируется?
Точно. hal у меня пропатчен и все ресурсы fat монтирует с cp866.
Кстати, если в винде вызвать cmd - в нем все имена корректно отображаются, а 
там кодировка cp866, что и требовалось доказать.

Re: kde+hal

В сообщении от Среда 10 января 2007 20:05 Artem Chuprina написал(a):
 А за кодировку содержимого отвечает уже совершенно другой механизм.
Согласен, но каждый раз перекодировать принимаемые/передаваемые файлы 
нереально. Так что все сайты, пересылаемые файлы и проч. держу в 1251 и жизнь 
наладилась. И вообще, после того, как PostgreSQL не сумел сдампать мои 
юникодные базы, я юникоду не верю. Впрочем, есть одно исключение - 
SQLite+Tcl+Perl, эта компания с юникодом дружит.

Re: kde+hal

On Wed, Jan 10, 2007 at 08:06:04PM +0300, Pechnikov Alexey wrote:
 В сообщении от Среда 10 января 2007 20:06 Dmitry Nezhevenko написал(a):
  Не верю. венда в юникоде длинные имена пишет. Файловая система точно с -t
  vfat монтируется?
 Точно. hal у меня пропатчен и все ресурсы fat монтирует с cp866.
 Кстати, если в винде вызвать cmd - в нем все имена корректно отображаются, а 
 там кодировка cp866, что и требовалось доказать.

codepage по сути вообще можно не указывать. Достаточно iocharset или utf8.

На счет cmd - туда скорее всего встроили перекодировщик имен файлов.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: kde+hal

Pechnikov Alexey - debian-russian@lists.debian.org  @ Wed, 10 Jan 2007 
20:06:04 +0300:

  Не верю. венда в юникоде длинные имена пишет. Файловая система точно с -t
  vfat монтируется?
 PA Точно. hal у меня пропатчен и все ресурсы fat монтирует с cp866.
 PA Кстати, если в винде вызвать cmd - в нем все имена корректно
 PA отображаются, а там кодировка cp866, что и требовалось доказать.

В cmd они отображаются в текущей кодировке.  Настроишь на 1251 - будут
отображаться в 1251.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Ошибка в мигель-ДНКазе
Mike Novikoff in [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kde+hal

В сообщении от Среда 10 января 2007 20:25 Dmitry Nezhevenko написал(a):
 codepage по сути вообще можно не указывать. Достаточно iocharset или utf8.

 На счет cmd - туда скорее всего встроили перекодировщик имен файлов.
cmd работает в 866. А 866 кодовая страница жестко завязана на ввод/вывод в 
1251, см. мануал.

Re: kde+hal

В сообщении от Среда 10 января 2007 20:25 Artem Chuprina написал(a):
 В cmd они отображаются в текущей кодировке.  Настроишь на 1251 - будут
 отображаться в 1251.
Повторяю, по умолчанию в руссой винде cmd в 866 и все имена файлов тоже. Можно 
изменить, но речь не об этом.

Re: kde+hal

On Wed, Jan 10, 2007 at 08:28:17PM +0300, Pechnikov Alexey wrote:
 В сообщении от Среда 10 января 2007 20:25 Dmitry Nezhevenko написал(a):
  codepage по сути вообще можно не указывать. Достаточно iocharset или utf8.
 
  На счет cmd - туда скорее всего встроили перекодировщик имен файлов.
 cmd работает в 866. А 866 кодовая страница жестко завязана на ввод/вывод в 
 1251, см. мануал.

Мануал к чему? man mount:
codepage=value
  Sets  the  codepage  for  converting  to shortname
  characters on FAT and VFAT filesystems. By default, codepage
  437 is used.
iocharset=value
  Character  set to use for converting between 8 bit
  characters and 16 bit Unicode characters. The default is
  iso8859-1. Long filenames are stored on disk in Unicode
  format.


-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: kde+hal

В сообщении от Среда 10 января 2007 20:37 Dmitry Nezhevenko написал(a):
 Мануал к чему? man mount:
Я про винду! Она в 866 пишет, а не в юникоде.

Re: kde+hal

Pechnikov Alexey - debian-russian@lists.debian.org  @ Wed, 10 Jan 2007 
20:28:17 +0300:

  codepage по сути вообще можно не указывать. Достаточно iocharset или
  utf8.
 
  На счет cmd - туда скорее всего встроили перекодировщик имен файлов.
 PA cmd работает в 866. А 866 кодовая страница жестко завязана на
 PA ввод/вывод в 1251, см. мануал.

cmd работает как скажут.  Доказательство в аттаче.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Если еда невкусная, вы просто на двое суток раньше времени сели обедать.
туристская поговорка


cmd.png
Description: PNG image

Re: kde+hal

Pechnikov Alexey - debian-russian@lists.debian.org  @ Wed, 10 Jan 2007 
20:30:36 +0300:

  В cmd они отображаются в текущей кодировке.  Настроишь на 1251 - будут
  отображаться в 1251.
 PA Повторяю, по умолчанию в руссой винде cmd в 866 и все имена файлов
 PA тоже. Можно изменить, но речь не об этом.

Короткие имена файлов на фате, в iso9660 и в самбе в винде в 866 всегда,
и это, кажется, не меняется.  Длинные (не вмещающиеся в 8.3) в iso9660
точно и, кажется, в vfat, хранятся в уникоде.  А вот в самбе передаются,
кажется, все еще в 866.  cmd же работает в той кодировке, в которой
скажут, и при показе имена файлов преобразует в нее, поэтому
апеллировать к тому, что показывает cmd, когда речь идет о кодировке
имен файлов, мягко говоря, не стоит.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Юзер обожает терпеть мелкие неудобства
Victor Wagner


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

doc-pdf

Hi all. 
Возникла необходимость преобразовать вордовый doc в pdf с цветовым
профилем CMYK. doc содержит черный текст, таблицы, цветные картинки.
OpenOffice документ открывает, чуть сьехало форматирование, но это не
проблема. 

После экспорта средствами OpenOffice и открытии pdf-ки в фотошопе видно,
что черный текст есть на всех цветовых слоях: C, M, Y, K. Пробовал
cups-pdf + редактирование конфига на предмет
dProcessColorModel=/DeviceCMYK. Результат тот-же. 

Что еще можно попробовать?

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: doc-pdf

Dmitry Nezhevenko - debian-russian@lists.debian.org  @ Wed, 10 Jan 2007 
21:28:29 +0200:

 DN Возникла необходимость преобразовать вордовый doc в pdf с цветовым
 DN профилем CMYK. doc содержит черный текст, таблицы, цветные картинки.
 DN OpenOffice документ открывает, чуть сьехало форматирование, но это не
 DN проблема. 

 DN После экспорта средствами OpenOffice и открытии pdf-ки в фотошопе видно,
 DN что черный текст есть на всех цветовых слоях: C, M, Y, K. Пробовал
 DN cups-pdf + редактирование конфига на предмет
 DN dProcessColorModel=/DeviceCMYK. Результат тот-же. 

 DN Что еще можно попробовать?

Насколько мне известно, нормальное цветоделение делают только
профессиональные адобовские инструменты предпечатной подготовки.  Кварк,
фотошоп, и т.п.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

hands-free BSD
(С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: doc-pdf

2007-01-10 Пенетрантность Иван Лох

On Wed, Jan 10, 2007 at 09:28:29PM +0200, Dmitry Nezhevenko wrote:
 Возникла необходимость преобразовать вордовый doc в pdf с цветовым
 профилем CMYK. doc содержит черный текст, таблицы, цветные картинки.
 OpenOffice документ открывает, чуть сьехало форматирование, но это не
 проблема. 

doc и цветоделение это оригинально...

 Что еще можно попробовать?

Я бы начал с развлечений с 

gs .. dProcessColorModel=/DeviceCMYK

Можно также импортировать OpenOffice документ в Scribus...

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: doc-pdf

On Wed, Jan 10, 2007 at 10:43:30PM +0300, Иван Лох wrote:
 On Wed, Jan 10, 2007 at 09:28:29PM +0200, Dmitry Nezhevenko wrote:
  Возникла необходимость преобразовать вордовый doc в pdf с цветовым
  профилем CMYK. doc содержит черный текст, таблицы, цветные картинки.
  OpenOffice документ открывает, чуть сьехало форматирование, но это не
  проблема. 
 
 doc и цветоделение это оригинально...
 
  Что еще можно попробовать?
 
 Я бы начал с развлечений с 
 
 gs .. dProcessColorModel=/DeviceCMYK

Я это в конфиг cups-pdf вписывал, резульатата не дало. 
 
 Можно также импортировать OpenOffice документ в Scribus...
 

Он только openoffice draw умеет и у меня не вышло импортировать даже
простейший документ.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: kde+hal

В сообщении от Среда 10 января 2007 21:29 Artem Chuprina написал(a):
 cmd работает как скажут.  Доказательство в аттаче.

Не знаю, что это доказывает - возможно, просто ничего не изменилось.
Нужно использовать что-то вроде

dirlog

при разных указанных страницах и смотреть, что реально в файл записалось. У 
меня получалось все в 866 кодовой странице. Что-там там было типа 
cmd /codepage, забываю помаленьку за ненадобностью...

Re: kde+hal