Заверните мне статью, пожалуйста!

From Wiki4Intranet
Jump to: navigation, search
m
 
Line 91: Line 91:
  
 
{{replicate-from-custiswiki-to-smwiki}}
 
{{replicate-from-custiswiki-to-smwiki}}
{{replicate-from-custiswiki-to-tools}}
+
{{replicate-from-custiswiki-to-4intranet}}
 
{{wl-publish: 2011-09-30 20:51:19 +0400 | StasFomin }}
 
{{wl-publish: 2011-09-30 20:51:19 +0400 | StasFomin }}

Latest revision as of 17:53, 5 April 2012

Часто при работе с вики-системой возникает задача «взять, и упаковать» получившуюся статью. Что бы потом послать ее кому-то (заказчикам, программному комитету конференций, редактору журнала, жене, и т.п.) у кого нет доступа к этой вике, а иногда даже нет доступа к интернету. И где-то рядом пасется близкая задача «упаковать, но на бумаге».

Для таких случаев в рунете сложился единый и нерушимый паттерн: «Засунуть в Ворд». Последствия пиратской эры — убежденность, что MS Word есть у всех (у нищебродов и красноглазых линуксоидов есть OpenOffice и LibreOffice), и таким образом, «Ворд» стал универсальным медиаконтейнером. Так например, если кому-то надо послать скриншот — скриншот делается кнопкой PrintScreen, создается Word-документ, картинка копипейстится в документ, документ посылается. Иногда ворд-документ создают, только чтобы скопипейстить в него и затем распечатать.

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

Текстовые процессоры — Word/Writer/… нужны только для одной задачи — сделать бумажный документ, который (увы, ограничение такого носителя как бумага) разбит на страницы. Откуда возникает куча проблем с оптимальной версткой, разбиением на страницы, размещением плавающих объектов (иллюстраций, таблиц), поддержание ссылочной целостности через номера страниц, и т.п.

Профессия верстальщика ужасна — тяжело, муторно, безденежно. Отлично выражается в анекдоте:

Через кладбище бредет скелет в лохмотьях. Его встречает другой скелет:

— Привет, ты тоже с ристалища?

— Ну да, верстальщик я, номер сдал, иду домой…

Всего этого нафиг на самом деле не нужно в электронном документе с непрерывной моделью верстки! И перегоняя HTML-контент через текстовый процессор, вы только выплескиваете ребенка, теряя все красивое стилевое оформление, и получая кучу проблем по бумажной верстке, бесплатно превращая себя в верстальщика.

Не делайте этого!

А что делать?

Если вдруг, вам нужно распечатать вики-статью на бумаге (ну есть такие любители), можно печатать сходу, в MediaWiki грамотно прописанные стили для печати, все распечатается правильными серифными шрифтами, без подчеркивания ссылок, причем все внешние гиперссылки будут распечатаны в скобках).

А если вам нужно куда-то послать эту статью, одним файлом, со всем форматированием, и картинками лучше использовать самый стандартный media-контейнер для HTML-документов:

  • MHTML, стандарт RFC 2557 еще прошлого тысячелетия (1999).

Его понимают почти все:

Вообще ситуация, что какие-то броузеры это не поддерживают «из коробки» это конечно фейл.

Так у Firefox баг на эту тему стоит аж с 1999 года, хотя есть аж два работающих расширения.

Призываю всех небезучастных пользователей FF зайти и проголосовать за этот баг! (Если знаете английский — можно добавить саркастических комментариев и т.п.).

  • Internet Explorer начиная с очень древних версий (так что «компьютерно непродвинутый потребитель» по-любому все отлично увидит).
  • MS Office — т.е. да, Word откроет и это, если заказчик, например, хочет активно порецензировать.
  • Остальные броузеры — либо открывают его сходу (Opera — проверил, Chrome — судя по википедии), либо, для пользователей FF — (небольшое увы!) нужно напрячься и поставить расширение.

Так для Firefox я пользуюсь Mozilla Archive Format, есть еще UnMHT (лично не проверял, но хвалят).

Поставив это расширение, Firefox сможет и просматривать MHT, и сохранять.

Итак, запомним, что MHTML — самый стандартный формат консервации HTMLя с картинками и стилями (да, он не оптимален с точки зрения размера и т.п., но если у вас не манга по мотивам Войны и Мира из 100500 картинок, то это все неважно).

Осталось понять, какую именно страницу сохранять в MHTML-формате, чтобы не попала всякая «навигационная обвязка».

Так вот, для этого мы сделали специальный MediaWiki-скин[1], «cleanmonobook», который берет все стилевое оформление от стандартного скина «monobook», но без навигации и всего лишнего.

У нас он вызывается ссылкой «Чистый HTML» («Clean page» для english). Используйте эту ссылку, сохраняйте и посылайте MHT-файл, если вам нужно дать кому-то на чтение и рецензирование вики-статью. (при печати оно также правильно напечатается — с подстановками URLов внешних ссылок и т.п.).

Ну, а если ваш получатель хочет вставить вашу статью (или отрывки из нее) в книгу, которую он пишет в текстовом процессоре (т.е. нужно заранее представить текстом все ссылки, убрать цветовую раскраску и т.п.), то тогда пошлите ему MHTML сделаннный из страницы по ссылке «Версия для печати».


Удивительно, что убогая метафора документа, как «набора страниц с полями» постоянно вылезает из могилы и убивает невинных прохожих. Какой прекрасный был Google Docs, когда его только купил Google — чисто электронный документ, т.е. верстка происходит только в броузере читателя, максимум использованного пространства, отличное юзабилити. Изначально внимание гугла ограничилось кривоприкрученной, но худо бедно работающей публикацией в Blogger. И пока не трогали, все было очень даже ОК. Почти Etherpad. Но нет таки, прошло несколько лет, и Google начал развивать Google Docs, притащив туда все скелеты из шкафов — «поля», «линейки», «разбиение на страницы». Скоро принесут туда еще и MSOffic-ный ribbon. Единственное ценное — интеграцию с Blogger, они, кстати отломали и не заметили. Ну а для меня на этом Google Docs закончился.

Остался единственный, неприятный вариант. Вам нужен именно страничный, текстовый документ. Например, вы должны сдать заказчику коробку распечатанной документации в соответствии с тридцатьчетвертым ГОСТом, надо которым будет измываться отдел нормоконтроля, оставшийся с 50х годов прошлого тысячелетия.

Вот только в этом случае, вам разумно

  • заранее подготовить единую составную статью (включающую статьи-разделы),
  • перегрузить ее в текстовый процессор ссылками «→M$WORD» или «→OOffice» (раньше они у нас были «закладками», в списке действий над статьей, но сейчас мы перенесли их в список «инструментов», в стиле monobook они слева).
  • приготовится к ручной доводке документа.

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

  • С одной стороны, уверяю — это копейки, по сравнению с накладными расходами ведения документации как в ламерском стиле («много вордовых файлов»), так и в крутом («LaTeX», «SGML Docbook»).
  • C другой, как уже я сказал, — старайтесь и этого по возможности избегать. Используйте MHTML, забудьте про текстовые процессоры. YAGNI!

  1. Да, в MediaWiki есть стандратный скрин dumphtml, но он совсем голый, без стилевых красот

Внимание! Данная статья выбрана для репликации в SMWiki.


Статья реплицируется в Wiki4IntraNet.