shoorick: (Рыжий)
Появилась задача преобразования из одного XML в другой. Метод понятен — это обсуждалось ужеXSLT.

XSLT

Только вот в голове — пусто, почти всё забыл. «Как так? — удивляешься, — Недавно же вроде делал...» Лезешь в багтрекер за деталями — выясняешь ненароком, что «недавно» — это восемь с половиной лет.

http://shoorick.ru/2016/11/12/forgiven-details/
shoorick: (Рыжий)
Open Journal Systems — многоязычная система: многие её части могут быть переведены на разные языки. Не все, конечно: например, в материалах статей некоторые поля по странной прихоти разработчиков (или просто по невнимательности) остались одноязычными и добавить в них возможность правильно хранить данные на нескольких языках — не самая простая задача: я, например, так её и не завершил. В версиях 2.4.* нормальной многоязычности статей не будет — возможно, такое положение и объясняет тот факт, что в России OJS не особо популярна — она без применения напильника непригодна даже для тех журналов, где надо всего лишь продублировать имя русского автора статьи латинскими буквами.

С переводом интерфейса дела обстоят чуть получше: переведено может быть почти всё. Но и тут не всё гладко: вместо gettext применяется другой механизм локализации, где ключами служат не фразы на естественном языке (например, английском), а строки вида where.what.someItem. Переводы хранятся в XML-файлах, раскиданных по дереву каталогов. Впрочем, бо́льшая их часть сосредоточена в locale/ и lib/pkp/locale.
Read more... )
shoorick: (Рыжий)
Голый WordPress работает. Jetpack — почти что нет: не взлетает при попытке привязки его к wordpress.com. Первым делом заподозрил, что не хватает каких-нибудь модулей PHP, но документация вордпресса говорит, что ничего не надо — достаточно веб-сервера (рекомендуются Apache или nginx), PHP ≥ 5.2.4 и MySQL ≥ 5.0, а на jetpack.me тоже ничего нужного нет.

За бубном тянуться лень, поэтому пойдём правильным путём: будем читать логи. Однако, там нифига нет. Оказывается, надо включить режим отладки — написать в wp.config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Такие настройки включат запись сообщений об ошибках, но не позволят сыпаться им на страницу.

Чтение логов с последующими экспериментами показало, что для работы вордпресса с джетпаком нужны хотя бы модули xml и ctype — без них джетпак не хочет общаться с wordpress.com. По умолчанию эти модули в PHP включены, однако некоторые экономные хостинг-провайдеры их отключают.
shoorick: (На катамаране)
Знакомые туристы-водники попросили залить в нафигатор таджикскую речку Шахдару. Я, взяв прибор, решил, что справлюсь быстро — нифига! Гугление с изучением специальных сайтов показало, что в интернетах дают только две карты: первая взята непонятно откуда (наверное, срисована с пятикилометровки, а то и с десятикилометровки), но с искомой речкой (весьма приблизительно нарисованной); вторая — из OpenStreetMap, с хорошо прорисованным городом Душанбе, но вообще без нужной реки — Горно-Бадахшанская автономная область там состоит, в основном, из пустоты.

Срисовал с доступных спутниковых снимков и Шахдару, и притоки её, и Гунт, куда сама Шахдара впадает. Но я не стал делать как три года назад (тогда я рисовал карту в GPSMapEdit, сохранял в польский формат, а затем перегонял в гарминовский img) — я стал рисовать на OSM, надеясь, что через несколько дней можно будет откуда-нибудь скачать готовую карту — так и самому проще, и для народа полезнее. Ну, конечно, соблюдая лицензионные ограничения, пришлось довольствоваться снимками Yahoo и Bing, которые в этом районе не лучшего качества — снимки с Google Maps / Google Earth в OSM обрисовывать нельзя.

Однако готовую карту я не получил: Таджикистан, похоже, мало кому интересен: его карты обновляются нечасто: на CloudMate лежат карты двухнедельной давности (при заявленных еженедельных обновлениях), на gis-lab.ru — и вовсе полуторамесячные (хотя некоторые российские регионы обновляются ежедневно).

Пришлось преобразовывать самому. Заодно экспериментально выяснил, что скачать карту Таджикистана целиком (да хотя бы Горного Бадахшана) нельзя — упоминающийся на страницах про mkgmap XAPI не работает, а обычный API даёт скачивать очень мало — не более трети квадратного градуса.

Другой вариант — открыть в JOSM множество кусочков, а потом сохранить их как один файл — тоже не лишён недостатков: первый — большое количество необходимых скачиваний, второй — mkgmap делает из подобного файла очень маленькую карту (в моём случае — весом 6 кБ), беря для неё не суммарную область, а лишь один из фрагментов. Оказалось, что второй недостаток вполне устраним: достаточно из получившегося OSM-файла убрать лишние тэги <bounds>, оставив только один, в котором и прописать координаты нужной области.

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

Карты для навигаторов Garmin, сделанные 27.08.2011 (то есть, сегодня) по второму (весь Таджикистан) и третьему (ГБАО, реки Гунт, Шахдара с притоками) методам какое-то время будут лежать на http://ge.tt/87jziC7
shoorick: (Default)
Поставил hugin под убунтой — стало лучше: в отличие от мандривы, требуется меньше телодвижений: почти не надо елозить мышью — всю работу по поиску ключевых точек (ну или почти всю) autopano-sift выполняет самостоятельно — в мандриве требовалось указать хотя бы одну пару (а лучше три) для всех соседних картинок. На больших панорамах, по десятку снимков, это утомляло. Особенно когда вместо мыши использовался ноутбучный тачпад..

Закат на Александровской сопке

Попутно написал на перле quick and dirty добытчик превьюшек из RSS-потока. Было, в общем-то, три варианта:
  1. Аккуратно разобрать полученный XML (на CPAN есть всякие модули).
  2. Взять с полки книжку, вспомнить про XSLT и сделать именно на нём. Можно даже без перла.
  3. Тупо выдрать нужное регекспами.
Тупо выдрал:
while ( $content =~ s{<item>(.+?)</item>}{}s ) {
    local $_ = $1;
    my ( $title ) = m{<title>(.+?)( / .+?)?</title>};
    my ( $link  ) = m{<link>(.+?)</link>};
    my ( $src   ) = m{<media:thumbnail\s+url="(.+?)"};

    print qq{<a href="$link"><img src="$src" alt="$title" title="$title"></a> };
}
Выдаёт такой список:

Закат на Александровской сопке Александровская сопка. Перед закатом Вид с Александровской сопки в сторону Миасса Вид с Александровской сопки на Златоуст и Таганай Скалы на Александровской сопке

Чую, что надо было всё-таки каким-нибудь из первых двух методов пользоваться, но поленился читать мануалы. Стыд и позор.
shoorick: (Default)
Увидел сегодня на UWDC ещё один метод быстрого создания презентаций — свердловчане Антон Халиков и Роман Иманкулов использовали в своих докладах S5: A Simple Standards-Based Slide Show System — систему, где презентация хранится в HTML-файле. S5, в отличие от takahashi, работает (вроде бы) в разных браузерах (а не только в файрфоксе < 3.6) — у меня оно успешно заработало в Google Chrome. Достигается это за счёт использования не специфического для мозиллы XUL-файла, описывающего интерфейс, а обычного HTML: синтаксис самого описания презентации получается более сложным по сравнению с простым текстовым описанием, применяемым в takahashi, но тому, кто знает HTML, это не страшно. Внешний вид, вроде, можно выбирать из готовых тем, а можно и перекрасить всё вручную правкой CSS-файла.

В качестве тренировки слепил коротенькую презентацию о Lingua::RU::Inflect — можно делать блиц-доклад? :-)
shoorick: (Default)
Подглядел у Алексея Капранова ([livejournal.com profile] quappa), выступавшего на перлбурге, интересный метод подготовки презентаций, который хорош для блиц-докладов. Точнее, я видел сделанные по этому методу презентации и раньше, но только сейчас покопался и понял, что к чему. Называется — takahashi. Такахаси ориентирован в первую очередь на вставку текста (доступен ряд команд разметки: выделение текста, моноширинный текст, можно вставлять растровые картинки).

Суть: вся презентация хранится в четырёх файлах: один из них — это исходный код презентации (очень мал), остальное — XUL-файл с интерфейсом (туда же можно засунуть и текст презентации либо заглушку, сообщающую о необходимости выбора исходного файла), обрабатывающий действия пользователя скрипт на JavaScript и стилевой CSS-файл. Суммарный вес — около 70 кБ. Для работы требует Gecko-based браузер, например, Mozilla Firefox.

Естественно, что весь механизм, в силу текстовой природы исходных файлов, легко дотачивается напильником в нужную сторону, если возникнет потребность. У меня возникла — обнаруженный пример не желал листать страницы по пробелу. Внешний вид презентации можно менять редактированием CSS-файла.

Исходный текст презентаций достаточно прост:
TITLE::Презентации
Упрощение процесса
подготовки презентаций
FOOTER::shoorick.ru
----
HEADER::Нафига?
0. Презентации [[EM:не нужны:EM]]
----
0. Презентации не нужны
1. Иногда всё-таки [[EM:нужны:EM]]
Посмотреть в действии (мозиллой!) можно на http://shoorick.ru/lj/slide/takahashi.xul?data=presentation.txt

Листать — кликом по любому месту экрана либо клавишами: пробелом, стрелками, PgUp, PgDn, Home, End, Enter, Backspace. Любители елозить мышью могут найти меню в верхней части слайда. Можно в процессе показа слайдов менять их содержимое прямо в браузере, а также рисовать поверх текста что угодно. Удобно!
shoorick: (Default)
Практика показала, что убунта, как и мандрива, не сильно расположена к чтению конфигурации иксов из /etc/X11/xorg.conf — она берёт настройки из кучи XML-файлов, разбросанных по домашнему каталогу юзера. В частности, настройки клавиатуры спрятаны в ~/.gconf/desktop/gnome/peripherals/keyboard/kbd/%gconf.xml

Зачем?!
shoorick: (Default)
Вчера сгоряча чуть было не написал программулину по рисованию дерева со структурой XML-файла. Даже, взяв напильник, слегка обточил какой-то старый скрипт разбора XML так, что он стал выдавать вместо текста вида
root
:  + first
:  :  + one
:  + second
+ three
исходный текст для GraphViz, из которого уже можно получать картинки.

Сегодня, погуглив на свежую голову, нашёл, что на CPAN, конечно же, есть нужный модуль. Теперь нарисовать дерево можно совсем просто:
#!/usr/bin/perl -w

use GraphViz::XML;
use File::Slurp;

my $data = read_file shift @ARGV;
my $graph = GraphViz::XML->new($data);
print $graph->as_png;
Получается такая картинка:
Структура XML-файла
Если нужен другой формат готовой картинки, то помимо PNG, модулем поддерживаются и другие форматы, как растровые (GIF, JPEG), так и векторные (PostScript, SVG) — для этого предназначены методы с вполне предсказуемыми именами as_gif, as_jpeg, as_ps, as_svg и т. п. А если не устраивает внешний вид графа, можно получить исходный dot-файл — для этого существуют методы as_canon и as_text: второй, в отличие от первого, выдаёт ещё и координаты вершин.

Можно ещё попробовать указать нужные свойства графа прямо в скрипте. Но это уже совсем другая история.
shoorick: (Default)
Пожалуй, ковыряние в XSLT до пяти утра — не самое правильное из занятий.

И взятая накануне в библиотеке книга Алексея Валикова «Технология XSLT» не особо помогла — автор то занимается занудным описанием элементов, используя нотацию EBNF (почти что регэкспы), то перескакивает непонятно куда, не объясняя, откуда взялись и что делают какие-то непонятные элементы. И оглавление там непонятное, и алфавитный указатель непривычно беден, и автор зачем-то пробелы и переносы строки обозначает как ? и < соответственно (ага, в книге про язык, в котором этих символов чуть менее, чем дофига), хотя в природе существуют └─┘ и . И бумага газетная, и набрано таймсом... В общем, по сравнению с книгами издательства O'Reilly — фигня какая-то.

И, кстати, экспериментируя весь вечер, я так и не понял, почему, когда я пишу <!DOCTYPE> объявляя сущности внутри документа, например,
<!DOCTYPE text [
<!ENTITY Yat "&#x462;">
<!ENTITY yat "&#x463;">
]>
то всё работает нормально, файрфокс споконо показывает файл, заменяя в нём сущности &Yat; и &yat; на Ѣ и ѣ, а стóит лишь вынести сущности в отдельный файл и сослаться на него — сразу начинает ругаться. В чём причина — я так и не понял.
shoorick: (Default)
Практика набора нот в MuseScore показала:
  1. при сохранении нот в виде графического файла, хоть PNG, хоть PDF, сохраняется скриншот со всеми имеющимися глюками, а вовсе не приличная картинка, которую может сделать LilyPond.
  2. при сохранении в формате LilyPond теряются все тексты кроме названий инструментов.
  3. при сохранении в формате MusicXML файл сохраняется в кодировке windows-1251, однако в файле указано, что он якобы в ISO-8859-1.
  4. Sibelius может читать созданный в MuseScore файл формата MusicXML. Но из-за предыдущего пункта кириллица в нём портится. И тексты песен пропадают.
  5. выбор клавиш для задания длительностей нот в MuseScore нелогичен: четверти — на 1, восьмые  — на 2 и так далее, однако целые — на 6, а половинки — на 7.
  6. порядок нот в создаваемых файлах, что в MusicXML, что в LilyPond — не такой как мне надо. Мне было бы удобнее, если бы ноты были сгруппированы по голосам, а не по тактам. Да и мусора много появляется при таком чередовании.
shoorick: (Default)

Послушав мнение коллег, решил что для преобразований XML → (X)HTML лучше всего подойдёт XSLT. Но чем преобразовывать? Первый попавшийся учебник рассказывал об интерфейсах на разных языках, но перла среди них на было.

Однако, перловый программер про CPAN вспоминает быстро. Недолго думая, нашёл XML::XSLT, в мане на который есть пример, подлежащий весьма небольшой обработке напильником надфилем до работоспособного состояния:

#!/usr/bin/perl -w

use strict;
use XML::XSLT;

die qq{XML Transformer\nUsage:\n\t$0 xml-file xslt-file\n}
    if ($#ARGV < 1);

my $xslt = XML::XSLT->new($ARGV[1], warnings => 1);

$xslt->transform($ARGV[0]);
print $xslt->toString;

$xslt->dispose();
Ковыряюсь дальше...

upd/18:15: ковыряние показало непрограммерский путь:

$ xsltproc xslt-file xml-file

shoorick: (Default)
Задача: надо преобразовать XML в HTML (или в XHTML — особой разницы нет).

Мысль первая — парсить ручками.
Мысль вторая — всё украдено до нас; может быть, имеет смысл взять, например, XML::Parser, распарсить XML им, а затем из получившегося дерева собрать HTML.
Мысль третья — а если пробовать XSLT? Проблема лишь одна — отсутствие знакомства с технологией. С другой стороны, надо же когда-то начинать.

Ув. тов. френды! Поделитесь, пожалуйста, опытом.
shoorick: (Default)
Оказывается, в Inkscape есть эффект, позволяющий почти автоматически красить наконечники стрелок в нужный цвет: Эффекты / Изменение контура / Раскрасить маркеры в цвет штриха. Но у меня оно не работает :-(
The inkex.py module requires PyXML. Please download the latest version from <http://pyxml.sourceforge.net/>.
Хотя py-xml установлен...

Пришлось идти уже знакомым обходным путём: ковырять XML:
  • Выделив нужный элемент, нажать Ctrl+Shift+X — откроется XML-редактор
  • у выделенного элемента смотрим значение атрибута style — там, помимо прочего, указан и ID маркера, например: marker-start:url(#Tail)
  • В XML-дереве ищем элемент <svg:svg ...><svg:defs ...><svg:marker id="нужный_нам_ID"><svg:path ...>
  • добавляем к атрибуту style нужные нам цвета: fill — цвет заливки, stroke — цвет штриха; или меняем значения на нужные, если цвета уже указаны
  • радуемся :-)

ЗЫ Поставил вчера на домашнюю машину виндузовую версию Inkscape. Работает...

Profile

shoorick: (Default)
shoorick

December 2016

S M T W T F S
    1 23
45678910
11121314151617
18 19 2021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 19th, 2017 03:18 pm
Powered by Dreamwidth Studios