Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
А что делать принимающей стороне, которой вместо редактируемого word присылают PDF?
Если принимающая сторона хочет именно в формате MS Word и именно в исходном форматировании, нужно использовать офисный пакет, причем желательно тот же самый. Ну или сменить принимающую сторону. :-)
Если принимающая сторона согласна на OpenDocument, достаточно rst2odt.
Если нужен документ в MS Word, но допустима замена неряшливого форматирования на правильное, можно к концу цепочки добавить OpenOffice (для odt→doc). Тогда офисным пакетом можно будет пользоваться в 2 клика, тормоза не повлияют на работу. Кстати, наверно, можно и без GUI, я просто не в курсе.
Если принимающая сторона согласна на OpenDocument, достаточно rst2odt.
Если нужен документ в MS Word, но допустима замена неряшливого форматирования на правильное, можно к концу цепочки добавить OpenOffice (для odt→doc). Тогда офисным пакетом можно будет пользоваться в 2 клика, тормоза не повлияют на работу. Кстати, наверно, можно и без GUI, я просто не в курсе.
Идея интересная, но, по-моему, оправдана только для случаев когда один и тот же документ неоднократно «отфутболивается» взад-вперёд, то есть когда воссоздание оформления оригинального документа на, имхо, довольно экзотическом языке окупится. К тому же, как я понял при беглом просмотре доков, для каждого выходного формата (pdf, html, odt) нужно создавать свои стили на своём языке.
маркдаун лучше.
А я надеялся на краткий обзор собственно возможностей reST, включая вышеупомянутые стили. Что там с такими вещами как отступы, колонтитулы, списки, содержание, контроль разбивки страниц и т.п? Хотелось бы получить ответы на эти вопросы прежде чем лезть в документацию с головой.
reST — не LaTeX, его нельзя использовать совсем для всего. Это одна из самых мощных и расширяемых разметок среди легко читаемых (наряду с Markdown, Textile и всякими вики-разметками).
Тем не менее, колонтитулы поддерживаются. И вот, кстати, неплохой tutorial по презентациям (в сравнении с LaTeX). Рассматривается и отбивка страниц (по заголовкам, вроде). Вполне в духе этой заметки. Жаль, я только сейчас на этот tutorial наткнулся.
В целом, reST, наверно, самый популярный язык для документации программ, написанных на Python. Питонисты обычно используют reST в сочетании со Sphinx. Документация самого Питона так и подготовлена. Естественно, это подразумевает легкое построение содержания произвольной глубины по набору документов (т.е. каждую главу можно хранить в отдельном файле).
Тем не менее, колонтитулы поддерживаются. И вот, кстати, неплохой tutorial по презентациям (в сравнении с LaTeX). Рассматривается и отбивка страниц (по заголовкам, вроде). Вполне в духе этой заметки. Жаль, я только сейчас на этот tutorial наткнулся.
В целом, reST, наверно, самый популярный язык для документации программ, написанных на Python. Питонисты обычно используют reST в сочетании со Sphinx. Документация самого Питона так и подготовлена. Естественно, это подразумевает легкое построение содержания произвольной глубины по набору документов (т.е. каждую главу можно хранить в отдельном файле).
«Легкость бытия», ха-ха. И ради чего все эти телодвижения?
Чтобы нормально работать, а не ждать, пока очнется текстовый процессор. И чтобы печатать, а не щелкать мышью. И диффы в VCS… кажется, я повторяюсь. Прочтите топик, там всё сказано.
Компьютер, на котором летает опенофис, можно собрать за астрономическую сумму в 15к рублей. И все проблемы, которые Вы описываете, просто исчезают. В чем же прелесть такого вот юникс-пути?
Компьютер, на котором летает опенофис, и компьютер, на котором летает Firefox с кучей вкладок, редактор, плеер,… И опенофис — это очень разные компьютеры.
Опенофис действительно часто тормозит. Если пользователь этого не замечает, у него либо весьма дорогой компьютер, либо просто привычка к заторможенности программ.
Опенофис действительно часто тормозит. Если пользователь этого не замечает, у него либо весьма дорогой компьютер, либо просто привычка к заторможенности программ.
… и да, скорость работы — лишь одна из нескольких проблем. Вы не читали топик или троллите.
Значит, вам не нужен контроль версий, вас устраивает форматирование входящих документов и вам нравится интерфейс/скорость офисных пакетов. ;-)
0. Предложенный вариант не предназначен для затыкания всех дыр. Всякий инструмент хорош на своем месте.
1. Нет, если диффать. Хотя it depends.
2. Нет, если диффать. Хотя it depends.
3. Иногда да. Сильно зависит от типа документа и ситуации.
Не знаю, зачем нужен спеллчекер, но без vim редактировать текст очень неудобно. Опять же, всё зависит от человека.
1. Нет, если диффать. Хотя it depends.
2. Нет, если диффать. Хотя it depends.
3. Иногда да. Сильно зависит от типа документа и ситуации.
Не знаю, зачем нужен спеллчекер, но без vim редактировать текст очень неудобно. Опять же, всё зависит от человека.
Предложите способ дифать .doc хотя бы. А то вы говорите «не нужно», а другого решения не предлагаете.
Рецензии интегрируются с какой-то из популярных VCS? Mercurial там, или git.
Должны, потому что так проще, если вы работаете не с парой документов, а со многими. Впрочем, зависит от приоритетов и привычек.
Что значит «сложнее плоского текста»? Если вас интересует вставка изображений, сложные таблицы, всякие хитрые ссылки, генерирование содержания и т.д., посмотрите Sphinx. Тот же reST.
Ну так в том и дело! :-)
Иначе всё было бы гораздо сложнее.
А вот объекты, которые бессмысленно сводить к плоскому тексту (например, картинки) — они блобами хранятся в VCS.
Вас что-то не устраивает в этом?
Честное слово, я с самого начала не могу понять, о чем спор. Я описал вариант решения трех проблем. Вы утверждаете, что он не нужен. Я объясняю, что он не нужен лично вам, но очень нужен, например, мне. Сейчас мы вроде как не можем решить, надо ли текст хранить как текст, если кроме текста есть что-то еще. Бр-р-р. Может, каждый просто будет поступать так, как считает нужным? Вот правда-правда, я не хочу вас переубедить, я просто хочу, чтобы мой опыт пригодился тем, у кого ситуация и требования совпадают с моими.
Иначе всё было бы гораздо сложнее.
А вот объекты, которые бессмысленно сводить к плоскому тексту (например, картинки) — они блобами хранятся в VCS.
Вас что-то не устраивает в этом?
Честное слово, я с самого начала не могу понять, о чем спор. Я описал вариант решения трех проблем. Вы утверждаете, что он не нужен. Я объясняю, что он не нужен лично вам, но очень нужен, например, мне. Сейчас мы вроде как не можем решить, надо ли текст хранить как текст, если кроме текста есть что-то еще. Бр-р-р. Может, каждый просто будет поступать так, как считает нужным? Вот правда-правда, я не хочу вас переубедить, я просто хочу, чтобы мой опыт пригодился тем, у кого ситуация и требования совпадают с моими.
Разделение форматов на текстовые и бинарные очень условно. reST — такой же формат как и остальные. Он сложнее плоского текста, на содержимое документа reST накладываются дополнительные ограничения. Среди его преимуществ — возможность работать без спец. ПО и версионификация стандартными средствами. Формат .doc этих преимуществ не имеет.
Нет, конечно. Но задача данного топика требует.
Т.е. вы выдумываете себе какие-то другие задачи и предлагаете способы их решения, а лучших способов решить задачу данного топика так и не предложили.
> избежать медлительных офисных пакетов, пользоваться любимым текстовым редактором, отделить содержание от представления, обеспечить высокую читаемость и прозрачность документов для VCS, легко сравнивать версии текстов
Хорошо, вы решили последнее и сказали, что первое «не нужно» (вам, но не neithere). Как быть с остальным?
Т.е. вы выдумываете себе какие-то другие задачи и предлагаете способы их решения, а лучших способов решить задачу данного топика так и не предложили.
> избежать медлительных офисных пакетов, пользоваться любимым текстовым редактором, отделить содержание от представления, обеспечить высокую читаемость и прозрачность документов для VCS, легко сравнивать версии текстов
Хорошо, вы решили последнее и сказали, что первое «не нужно» (вам, но не neithere). Как быть с остальным?
Самый лучший способ сравнивать версии .doc — использовать монструозный проприетарный офисный пакет, не работающий на ряде платформ.
Самый лучший способ сравнивать версии текста — использовать простой текст и нормальные системы контроля версий по вкусу.
Самый лучший способ сравнивать версии текста — использовать простой текст и нормальные системы контроля версий по вкусу.
Т.е. вы признаёте что ваше решение — это решение какой-то другой задачи, а не представленной в первом абзаце топика.
Т.е., название программы — Word — вводит в заблуждение. И mp3 не музыка, потому что туда можно встроить и текстовые комментарии, и даже изображения. Да, да, да. )
Вот reST именно этим и лучше: отдельно чистый текст, чистые изображения, чистые стили — и нет каши, которую потом можно разобрать только тяжелой артиллерией.
Вот reST именно этим и лучше: отдельно чистый текст, чистые изображения, чистые стили — и нет каши, которую потом можно разобрать только тяжелой артиллерией.
Понимаете, это всё очень хорошо, но если я и дома, и на любом сервере использую одни и те же программы (например, vim, diff, hg) для работы с «околокомпьютерным» текстом, то не гораздо удобнее с их же помощью работать и с текстом любой другой тематики. И действительно проще прицепить конверторы на вход/выход, чем поддерживать и углублять навык работы в еще одной сложной узкоспециализированной среде для достижения того же результата. И невозможность прямой работы с материалом выглядит существенным недостатком.
s/то не/то мне/
Tonight on «It's the Mind», we examine the phenomenon of deja vu. That strange feeling we someti.........mzget…
Ладно, еще раз пластинку покрутим для истории, вдруг пригодится кому.
1. Получаем жуткое месиво под названием «служебная записка», пропускаем через aw (1 сек), получаем чистый текст. Сохраняем как есть.
2. Копируем как reST-файл, приводим в порядок (1-3 мин), отныне все новые служебки _мы_ будем начинать отсюда. Отправляем на печать.
3. Приходит новая служебка; пропускаем через aw (1 сек), диффаем с предыдущим вариантом (2 сек), видим 2-3 изменения, добавляем их в reST (20 сек), отправляем на печать.
Т.о., единоразовые затраты в пределах пары минут, а повторяющиеся сравнимы с временем запуска OOo и включают в себя проверку корректности изменений.
Вы пробовали привести в порядок документ, сверстанный типичным пользователем? Если вам это не интересно, перестаньте меня донимать вопросами, пожалуйста. Если интересно, то сами знаете, что проще переделать — и я вам показываю, как.
Наверно, я не прав, что сделал акцент на antiword'е, надо было подчеркнуть, что документы удобно верстать в reST с нуля. С другой стороны, показалось занятным, что с минимальными усилиями в такую системку втыкается и более-менее типичный workflow.
Ладно, еще раз пластинку покрутим для истории, вдруг пригодится кому.
1. Получаем жуткое месиво под названием «служебная записка», пропускаем через aw (1 сек), получаем чистый текст. Сохраняем как есть.
2. Копируем как reST-файл, приводим в порядок (1-3 мин), отныне все новые служебки _мы_ будем начинать отсюда. Отправляем на печать.
3. Приходит новая служебка; пропускаем через aw (1 сек), диффаем с предыдущим вариантом (2 сек), видим 2-3 изменения, добавляем их в reST (20 сек), отправляем на печать.
Т.о., единоразовые затраты в пределах пары минут, а повторяющиеся сравнимы с временем запуска OOo и включают в себя проверку корректности изменений.
Вы пробовали привести в порядок документ, сверстанный типичным пользователем? Если вам это не интересно, перестаньте меня донимать вопросами, пожалуйста. Если интересно, то сами знаете, что проще переделать — и я вам показываю, как.
Наверно, я не прав, что сделал акцент на antiword'е, надо было подчеркнуть, что документы удобно верстать в reST с нуля. С другой стороны, показалось занятным, что с минимальными усилиями в такую системку втыкается и более-менее типичный workflow.
Чёрт, только здесь понял, для чего нужна была вся эта канитель — вам регулярно присылают много страниц ЦУ в ворде, изменяя только пару строчек.
Я бы, наверное, попытался использовать VBA или решить проблему на человеческом, а не техническом уровне — требованиями писать более понятно и выделять изменения в документе штатными средствами.
Я бы, наверное, попытался использовать VBA или решить проблему на человеческом, а не техническом уровне — требованиями писать более понятно и выделять изменения в документе штатными средствами.
Присылают не ЦУ, а материалы для очеловечивания и дальнейшей публикации. Увы, на той стороне проблема не решается.
Но еще раз отмечу, что это вторичное применение «системы». Первичное — подготовка документов с нуля, полный замкнутый цикл. Я об этом мечтал при написания диссертации, но тогда никаких rst2pdf и в помине не было, а LaTeX казался (и, наверно, был) оверкиллом.
Но еще раз отмечу, что это вторичное применение «системы». Первичное — подготовка документов с нуля, полный замкнутый цикл. Я об этом мечтал при написания диссертации, но тогда никаких rst2pdf и в помине не было, а LaTeX казался (и, наверно, был) оверкиллом.
Не знаю, потому что винду я снес несколько лет назад =)
Из docx обычно извлекаю текст через Google Docs.
Из docx обычно извлекаю текст через Google Docs.
qme.ru
Правда, работало только в IE. Но под виндой это не проблема =)
Правда, работало только в IE. Но под виндой это не проблема =)
Проверил кстати что сохраняет офис.
Я бы не сказал что все так плохо.
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1251">
<meta name=Generator content="Microsoft Word 14 (filtered)">
<style>
<!--
***
-->
</style>
</head>
<body lang=UK>
<div class=WordSection1>
<h1><span lang=EN-US>Hello</span></h1>
<p class=MsoNormal><span lang=EN-US>Some test</span></p>
</div>
</body>
</html>
Я бы не сказал что все так плохо.
Т.е. берем «неправильный» формат Word, выбираем только текст, вручную форматируем заново, сохраняем в любой из «правильных» форматов… Из причин, нормально понял только про скорость и возможность хранить изменения. «Нормальные кроссплатформенные средства» — это скорее не причина, а инструмент для ее решения.
По поводу скорости, то сколько итераций вопрос-ответ-… должно быть, чтобы ваш вариант был быстрее, чем открыть в медленном OO?
OpenOffice.org сейчас под рукой нет, но в MS Word есть замечательный режим рецензирования.
Я правильно понимаю, что любая вставленная картинка приведет к ее потере?
А сложное форматирование придется делать через Ж… Т.е. открыть в тормозном ОО, сделать текст, подогнать форматирование до уровня тормозного ОО, сохранить в какой-то «правильный» формат.
По поводу скорости, то сколько итераций вопрос-ответ-… должно быть, чтобы ваш вариант был быстрее, чем открыть в медленном OO?
OpenOffice.org сейчас под рукой нет, но в MS Word есть замечательный режим рецензирования.
Я правильно понимаю, что любая вставленная картинка приведет к ее потере?
А сложное форматирование придется делать через Ж… Т.е. открыть в тормозном ОО, сделать текст, подогнать форматирование до уровня тормозного ОО, сохранить в какой-то «правильный» формат.
Про «итерации вопрос-ответ» не понял. Одно точно могу сказать: пока OOo запускается, я уже внесу правку через vim и отправлю документ на печать.
Antiword не сохраняет картинки, да. Их можно втыкать отдельно. Это будет разумно, если вы составляете документ самостоятельно.
Насколько сложное форматирование? reST довольно мощный, это не вики-разметка. Если не хватает — разумеется, не надо его притягивать за уши, берите LaTeX.
Еще раз: описанное решение не призвано заткнуть все дыры.
Antiword не сохраняет картинки, да. Их можно втыкать отдельно. Это будет разумно, если вы составляете документ самостоятельно.
Насколько сложное форматирование? reST довольно мощный, это не вики-разметка. Если не хватает — разумеется, не надо его притягивать за уши, берите LaTeX.
Еще раз: описанное решение не призвано заткнуть все дыры.
Чем бы их Word получать reST с сохранением форматирования (хотя бы выделением заголовков, жирности, курсивности и т.д.)?
Хорошо бы, угу. Хотя я обычно получаю файлы, в которых заголовки оформлены нажатием кнопочки «жирный» и выбором размера шрифта. Ну и всё в этом духе. В результате проще взять чистый текст и привести его в норму, чем возиться с первоначальной кашей. В хорошем тексте то или иное выделение встречается довольно редко и его без труда можно перенести вручную.
Аналогично получаю файлы, в которых заголовок отмечен жирным. Но не всегда хочу вдумчиво перечитывать весь файл. Одно дело — найти, где заголовок отмечен жирным — и исправить (в reST), другое дело — вдумчиво перечитывать файл в поисках подзаголовков. Если же в длинном тексте автор одно слово выделил курсивом — то твоим методом ты это слово почти наверняка упустишь.
ЗЫ. Я для себя в свое время использовал wiki-разметку вместо reST и html2wiki — простые теги он преобразует в вики-разметку, сложные оставляет прямо html — т.е. сразу видно, где надо руками не забыть сконвертить. Из ворда сначала приходилось конвертить в HTML…
ЗЫ. Я для себя в свое время использовал wiki-разметку вместо reST и html2wiki — простые теги он преобразует в вики-разметку, сложные оставляет прямо html — т.е. сразу видно, где надо руками не забыть сконвертить. Из ворда сначала приходилось конвертить в HTML…
P.S.: man antiword :)
в т.ч. antiword -f foo.doc
в т.ч. antiword -f foo.doc
У меня не установлен. Поэтому поясни, что означает -f?
Ой. Я правильно понимаю, что antiword выдаст жирный текст как *text*, а reST потом поймет *text* как курсив?
В reST нет «жирного» и «курсива», тк это семантическая разметка. Там есть emphasis и strong emphasis (транслируются в em и strong). Да, произойдет смещение акцентов. Антиворд генерит дурацкую вики-разметку. Ну и понятно, что тупо прогонять результат через регексы в данном случае небезопасно. Я думаю, что при необходимости соблюсти совершенно правильное форматирование надо не сразу гнать в reST, а сначала в какой-то из XML-based форматов (напр.,
antiword -x db foo.doc > foo.xml && db2rst.py foo.xml foo.rst).
Может вам стоит девушку завести 0_о
А то, чувствую, слишком много свободного времени на всякие глупости.
А то, чувствую, слишком много свободного времени на всякие глупости.
В дополнение — замечательная статья «Документооборот: LaTeX to All, или мы будем прогибаться под испорченный мир» (Владимир Игнатов, 2004)
wvware.sourceforge.net/ умеет из doc делать LaTeX. Мне пока не на чем попробовать, но обещают читабельный и чистый LaTeX.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Легкость бытия: Antiword, reST