From: "Alexander Cherepanov" Received: by relay1.vsu.ru (CommuniGate Pro PIPE 5.2.16) with PIPE id 197922052; Sun, 23 Aug 2009 01:28:14 +0400 X-drweb-hash: Received: from brown.mccme.ru ([213.171.48.226] verified) by relay1.vsu.ru (CommuniGate Pro SMTP 5.2.16) with ESMTPS id 197922057 for CyrTeX-ru@vsu.ru; Sun, 23 Aug 2009 01:27:55 +0400 Received-SPF: pass receiver=relay1.vsu.ru; client-ip=213.171.48.226; envelope-from=cherepan@mccme.ru Received: from [213.171.48.245] (helo=localhost) by brown.mccme.ru with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mey81-000O4H-E2 for CyrTeX-ru@vsu.ru; Sun, 23 Aug 2009 01:28:01 +0400 Message-ID: <000401ca236f$5013d720$0100007f@localdomain> To: "Cyrillic TeX Users Group" References: <000401ca2053$a42457a0$0100007f@localdomain> Subject: =?koi8-r?B?UmU6IPPUyczF18ney8kgxMzRIPTF6MEg0M8t0tXT08vJ?= Date: Sun, 23 Aug 2009 01:27:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 FL-Build: Fidolook 2002 (SL) 6.0.2800.85 - 28/1/2003 19:07:30 X-SA-Exim-Connect-IP: 213.171.48.245 X-SA-Exim-Mail-From: cherepan@mccme.ru X-SA-Exim-Scanned: No (on brown.mccme.ru); SAEximRunCond expanded to false X-Bounce-ID: brown.mccme.ru X-DrWeb-FlyTrap-Class: SPAM X-DrWeb-FlyTrap-CID: 2 X-DrWeb-FlyTrap-ID: 45534142 X-Junk-Score: [XXXXXXXXXX] Hello, Olga! You wrote to "Cyrillic TeX Users Group" on Thu, 20 Aug 2009 00:09:42 +0400: >>> У меня правила + зрительное восприятие -- в аббревиатуре зрительное >>> расстояние >>> между буквами, можно сказать одинаковое в виде обычного пробела, а >>> точки "вписываются" в это пространство. >> >> Но в правилах-то ничего про зрительное восприятие в этой области не >> сказано? А если мы начинаем изменять правила в соответствии со своими >> представления, мы выходим на тонкий лёд. С одной стороны, правила >> устарели, ибо были предназначены совсем для другой техники, с совсем >> другими возможностями и ограничениями. И даже тогда правила были не >> совсем стройными (кое-где Мильчин пишет, что, мол, тут ГОСТ неверен, а >> это в ГОСТе не описано). С другой стороны, если начинать изменять >> правила, то где остановиться... > Я правила не меняю, в аббревиатурах используется обычный межсловный > пробел, просто там, где точки он чуть меньше, вроде бы как точка > \rlap'ится... Однако в других местах, где встречается точка, (например, между предложениями) этого не делается? >>> И еще: пробелы в аббревиатурах сжимаются, но _никогда_ не >>> растягиваются. >> >> А откуда такое правило, если не секрет? >> Насколько я помню, в правилах редко описывается, как могут меняться >> разные пробелы, в основном, просто указывается размер. Так что >> адаптировать имеющиеся правила под tex довольно сложно. > Просто личная симпатия. А потом эти аббревиатуры воспринимаются мной > как слово. > Ну чем они отличаются от тех же ГОСТ, вуз и прочего? Только точками. > В конце концов я повторю, что можно и опции-команды сделать. С одной стороны, мне симпатична эта идея, с другой, это нарушение правила, что все пробелы в строке должны быть одного размера. >>>>> Чтобы работал под inputenc. >> >>>> А надо?:-) >> >>> Конечно, сейчас правильно делать русские документации в inputenc. >> >> Мне казалось, что в издательствах никто inputenc использовать не будет >> -- уж больно он медленный. > Сейчас машины быстрые. И ускорение работы tex'а раза в два не сделало бы Вашу работу более комфортной? >>> Уж во всяком случае мне тексты уже присылают уже с этим пакетом. >> >> Ну, присылают-то, наверное, всё, что только можно. Но потом это всё >> равно конвертируется в какой-нибудь внутренний формат. > Это верно. Хотя хочется переделывать поменьше. Так переделывать-то почти ничего и не нужно -- заменить \usepackage{inputenc} на что-нибудь другое. >>> Хорошо бы чтобы было и нашим и вашим... >> >> Основная часть не зависит от того, используется ли inputenc, так что >> там проблем не будет. А для того, что зависит, действительно, хорошо >> бы иметь поддержку inputenc. Вот только непонятно, в каком объёме. >> Поддерживать возможность inputenc'а переключения кодировки на лету, >> я так понимаю, не предлагается? > Это про кого? Про Ваши tr-abbr-*.sty . >>> Сейчас мы перешли в >>> издательство, где делается школьная литература и русские формулы уже >>> актуальны. Уж во всяком случае \displaystyle обязателен. Поскольку он >>> все-таки раздувает >>> книгу да и смотрится крупновато (я, конечно, уже привыкла к >>> уменьшенному ;) ) >>> то неплохо размер дробей уменьшить. Это не идет речь о книгах, где >>> формул около 90%! >>> Хотя и в такую книжку я их тоже пихнула как-то раз...(между прочим, >>> она должна быть меньше, чем с классическими -- ведь выключные >>> формулы уменьшились, а их там пруд пруди!) >> >> Насколько я помню, ещё в российских формулах нужно 4 размера шрифтов >> вместо 3-х tex'овских. Видимо, это означает, что все изменения >> размеров в формулах надо делать вручную, а не просто настроить >> tex'овский механизм. В этой области тоже продвижения есть > почему вручную? У меня все автоматически. Я имел в виду, что придётся выкинуть все tex'овские математические стили (включая \mathchoice) и создавать свою машинерию, в частности, делать ^ и _ активными и заставлять их следить за стилями (скажем, помещая индексы внутрь формул внутри \hbox'а с нужным размером шрифта). В общем-то, не так уж и сложно, но изменения довольно большие и я ещё не думал, какие проблемы вылезут. У Вас что-то подобное, или Вы как-то по-другому решили эту проблему? > Кстати есть стилевик в ncctools. Мне Александр рассказал. > Я его испытаю, как только найдутся время и силы. >>> Похоже, положение нашего бабеля все то же... >>> Я, как говорила его запатчила: во-первых сделала неразбиваемым >>> \cdash (команду куда хочешь можно пихнуть, а кавычка в каком-нить >>> Makeindexe просто исчезнет), потом доопределила --= в пару к --~ >>> поскольку эта тильда раскрывается в тех же заголовках и еще. >>> Да! последний бабель тут выдал такую гадость! Неровен час >>> использовать MakeUppercase в заголовках -- он начнет разыскивать >>> опцию RUSSIAN... >> >> Боюсь, я не вполне понимаю, что Вы имеете в виду. > Я в одном из предыдущих писем выложила патчик. Речь идет о версии > бабеля 3.8. До этого ничего такого не было Это, наверное, про \cdash. А что за гадость MakeUppercase? >>>>> И заодно о многоточиях. Почему бы не использовать \hbox >>>>> to\x{\hidewidth<знак, который >>>>> может быть и с кернами>\hidewidth}, где \x-ширина точки? >>>> >>>> Вопросительный знак будет прилипать к предыдущему символу? >> >>> Если это точка, то просто нависнет, а в случае с соседом в виде >>> восклицательного знака >>> этого делать не нужно -- здесь уже воспринимаются знаки целиком, а не >>> их точечки. >> >> Мне показалось, что Вы предлагается сделать что-то типа такого: >> >> \setbox0\hbox{.} >> \def\test{% >> \hbox to\wd0{\hidewidth?\hidewidth}% >> \kern\fontdimen3\font.\kern\fontdimen3\font.} >> Text\test >> >> При этом по размерам ?.. получается в точности как ... , но >> вопросительный знак получается сильно ближе к слову, нежели обычно. >> Или Вы что-то другое имели в виду? > В общем-то да. Может еще там косметика какая-то нужна... Проблема в том, что мы должны к вопросительному знаку подходить с разных сторон по-разному: слева мы должны работать с ним, как с вопросительным знаком, чтобы расстояние от слова было хорошее, а справа мы должны работать с ним, как с точкой, чтобы расстояние до следующей точки было, как в многоточии. Поэтому легко нам всё равно не отделаться. Остаётся выбор -- вычислять нужный сдвиг во время выпонения или вычислить его заранее и вписать ответ в макрос. >> Все "пиратские" книжки с vsu.ru убрали:-( > А непиратские ГОСТы и вовсе пропали... Да уж, это совсем зря. Саша -- Alexander Cherepanov My mail is cherepan at mccme dot ru