Распознавание шрифта

Иногда возникает необходимость узнать какой шрифт был использован в той или иной картинке.

Задача казалось бы довольно простая - раз уж у нас существуют средства, позволяющие распознавать сам текст с картинки, то уж распознать шрифт, которым этот текст написан не должно быть очень сложно.

На самом деле задача обычно состоит из двух подзадач - распознать шрифт, которым написан исходный текст, а также подобрать из имеющихся в данный момент на машине шрифтов наиболее к нему близкий.

Для решения есть несколько более или менее автоматизированных средств:

1. WhatTheFont - web-приложение, которое позволяет загрузить картинку и автоматически пытается определить шрифт. Изображение нужно сначала специальным образом подготовить (подробные инструкции есть на сайте)
   
   
2. Identifont , ITC Fonts, Fonts.com - содержат небольшую "экспертную" систему, которая задаст некоторое количество вопросов про интересующий шрифт и выдаст список наиболее подходящих шрифтов
   
   
3. FontMatch - windows приложение, позволяющие загрузить изображение буквы и пытающаяся найти среди имеющихся на компьютере шрифтов подходящий
   
   
4. Kleptomania - отличное windows-приложение, предназначенное в основном для того, чтобы копировать текст из окон, которые этого не поддерживают. Также умеет распознавать и шрифт, которым написан текст.
   
   
5. FineReader или другая полноценная программа распознавания текста. Все в них хорошо, кроме того что при их использовании не покидает ощущение стрельбы из пушки по воробьям.
   

Мой выбор - (4) - Kleptomania - самая удобная, быстрая и к тому же бесплатная программа.

P.S. Ну если честно, то в итоге все равно в Word-е глазами на шрифты смотрел и вручную сравнивал :-) На всякий случай ...

Производительность XSLT

XSLT не очень "быстрый" язык. Разные XSLT процессоры работают по разному, и пользуются разными методами оптимизации.

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

В XSLT существуют потенциально медленные конструкции, при этом разные процессоры могут с разной скоростью исполнять разные инструкции, поскольку по-разному оптимизированы.

В этой заметке я попытался собрать некоторые наблюдения по поводу производительности XSL.


XSLT процессор и ОС

Иногда может показаться так, что один и тот же XSLT процессор по разному работает на под разными ОС.

Убедитесь что вы действительно используете один и тот же процессор и одну и ту же версию, иначе все ваше сравнения окажутся пустой тратой времени.

Про переменные

Для большинства замедлителей почти всегда действует общий совет - вычисляйте каждую вещь только один раз. Результат любого вычисления можно сохранить в переменной, и после этого спокойно использовать.

count

Ф-я count вычисляет количество узлов в наборе и работает иногда чрезвычайно медленно. Если есть необходимость её использовать, то старайтесь вызывать её минимальное количество раз и помещать вычисленное значение в переменную.

preceding:: и другие

Использование preceding и других "осевых" функций (preceding-sibling, following, following-sibling) может существенно замедлить XSL преобразование, поэтому необходимо постараться от них избавиться.

Часто preceding и preceding-sibling используются для организации группировки или выборки уникальных элементов. Вместо этого можно пользоваться методом Мюнха(xsl:key + generate-id()).

//

Использование '//' для поиска также может сильно замедлить преобразование, особенно в случае большого файла, с большим количеством узлов. Здесь, также как и в случае группировки, стоит подумать об использовании xsl:key.

Проход по узлам

Старайтесь осуществлять "проход" по коротким спискам.

Использование ключей

Ключи (элемент xsl:key и функция key) могут очень сильно улучшить производительность XSL программы, особенно если в ней производятся "большие" поиски.

В зависимости от реализации использование элемента xsl:key приводит к созданию XSL процессоров внутреннего индекса, за счёт чего достигается очень быстрый доступ к соответствующим узлам.

Использование сокращённого вычисления (short-circuiting)

В XSL, как и во многих других языках программирования вычисление булевых выражений осуществляется при помощи сокращённого вычисления. Это значит что вычисление прекращается, как только ясен результат. Например в выражении [1 OR (всё-что-угодно)] значение выражения 'всё-что-угодно' вычисляться не будет, поскольку ясно, что общий результат от этого не изменится.

А раз так, то стоит в логических вычислениях (xsl:if, xsl:when) ставить в начало те выражения, которые требует меньше времени для вычисления.

Не стоит полагаться на xsl:message

Очень часто мы пользуемся в своей работе "отладочной печатью". В случае XSL ф-ю печати выполняет элемент xsl:message. Этот элемент тем не менее не совсем прост. Дело в том, что он нарушает необходимое в функциональном языке (а XSL - функциональный язык) свойство отсутствия побочных эффектов. На самом деле порядок вывода xsl:message не обязательно будет таким, как нам кажется, он может зависеть от используемого XSL процессора. Поэтому для отладки, на мой взгляд, лучше пользоваться встроенными средствами трассировки, имеющихся практически во всех процессорах.

И напоследок

Каждый XSLT процессор работает немного по-своему. Совершенно необходимо тестировать подготовленное XSLT преобразование именно на том процессоре, который будет работать в реальной версии продукта.

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

Также, помочь определить проблемные места программы на XSLT может профилирование, то есть измерение времени выполнения определенных участков кода. Практически все современные IDE для работы с XML и XSLT (например Altova XMLSpy, Stylus Studio, oXygen XML) предоставляют также средства профилирования.

Что ещё почитать про производительность XSLT

1. Предложения разработчиков процессора Xalan
2. Советы от Microsoft
3. Список советов по улучшению производительности XSLT из XSLT FAQ (в том числе от Michael Key)
4. Немного теории: Michael Key: XSLT and XPath Optimization.
   

Enterprise улетает с Альтаира?

Недавние мои собственные посты на темы "portable applications" и по поводу "носителей информации", а также комментарий Morph натолкнули меня на следующие размышления.

Действительно, сейчас наблюдаются несколько тенденций, которые тянут "персональные данные" в противоположные стороны.

Все своё ношу с собой

С одной стороны, portable программы получили большое развитие. Все больше программ становятся независимыми от реестра (в windows мире), поскольку хранят свои настройки в собственных конфигурационных файлах (и .NET только способствует этому). А раз так, то они по сути все ближе приближаются к portable миру. Flash-ки и внешние USB-винчестеры становятся все более ёмкими и надёжными, возможность полностью носить с собой всю свою рабочую "среду" является все более и более реальной (например "нафаршированная" флэшку n-Key Flash).


Omnia mea mecum porto

:-) Да, на самом деле второй заголовок - это первый на латыни. Но вот история исходного выражения говорит нам о том, что в дни завоевания персами греческого города Приены за толпой беглецов, еле тащивших на себе тяжёлое имущество, спокойно шёл налегке мудрец Биант. Когда его спрашивали, где его вещи, он, усмехаясь, говорил: «Все, что имею, всегда ношу при себе». На самом деле он вероятно имел ввиду, что ум, знания и внутренняя сила человека гораздо важнее, чем какие-то конкретные вещи и материальные накопления.

Сейчас есть возможность не носить с собой ничего. Google, а сейчас и многие другие компании создали в Сети такую среду, что многим людям достаточно иметь компьютер, подключенный к интернет, а все необходимы им программы и данные они могут найти в сети. Вся почта в gmail, все документы в Google Docs или подобных системах.

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

Большой брат

Крупные компании исповедуют конечно же свой путь. Они запрещают подключать флешки, пользуются внутрикорпоративной почтой и так далее. Закон Сарбейнс-Оксли и все такое.
В большой компании не нужен "персональный компьютер". любой сотрудник может подойти к любому компьютеру и работать( ну конечно это натяжка, но ведь они к этому стремятся, это так сказать недостижимый идеал). [большие компании бывают разные и я здесь конечно говорю в основном НЕ про компании-производители программного обеспечения].

Тем не менее, мне кажется что на самом деле большие компании давно идут по пути "централизации" информации. Ведь нет большой разницы между тем, что у обычного пользователя почта хранится в Google или на корпоративном Exchange сервере. Разница есть с точки зрения компании - хранится ли информация у самой компании или у "чужой" компании. А вот с точки зрения человека разницы нет - его данные хранятся не у него в обоих случаях.

Размышления

И что же мы видим? Мне видится два момента.

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

Во-вторых, автономные устройства пока что проигрывают "сетевым" даже по техническим характеристикам. Их ёмкость невелика, они не всегда удачно сочетаются со всеми имеющимися в различных местах компьютерами, надёжность оставляет желать много лучшего.

В 1975 году появился компьютер Altair, что ознаменовало собой начало эры персональных компьютеров. Говорят, что название компьютера было придумано дочерью технического редактора журнала "Popular Electronics" Леса Соломона, поскольку в тот день корабль Enterprise из популярного сериала "Звездный путь" должен был направится именно на Альтаир. Прошло 32 года. Эра персональных компьютеров закончилась? Enterprise улетает с Альтаира?