Pull to refresh

Comments 26

Супер идея. Давно в голове зрело нечто подобное. Правда для студенческих нужд. Коллективные работы делать. Может есть какие-нибудь комбинации софта более подходящие?
возможно, и есть. я написал только о том, с чем работал сам.
Я пытался решать подобную проблему, и как раз теми инструментами, которые описаны выше (просто удивительное совпадение), и тоже столкнулся с тем, что не существует нормального способа работать с odt в subversion. На самом деле возможность просматривать diff-ы в odt - это не самая большая проблема, и существуют утилиты, которые её решают. Значительно более серьезная проблема - это трехстороннее слияние документа (merging), когда делаешь svn up, и он тебе из трех документов (предыдущая версия, обновленная версия из репозитория, твоя версия) должен сделать что-то среднее.

Пытаясь по-всякому выкручиваться, я сначала попробовал использовать wiki или что-нибудь вики-подобное (типа markdown). Такой вариант довольно неплохо подходит для внутренней документации или для документов, которые не предъявляют серьезных требований к оформлению.

Мой случай как раз оказался не таким (оформление должно было быть ГОСТовским), поэтому я пока остановился на суровом варианте - использовать LaTeX. У него нет никаких проблем с diff-ами и системами управления версиями, но есть, конечно, другая серьезная проблема - с наскоку его не освоишь. Я в общем согласен, что заставлять верстать в LaTeX-е секретарш - это чересчур жестоко и малоперспективно, но вот когда речь идет о "студенческих нуждах", пожалуй, лучшего средства не найти.
Думаю, что не проблема научить секретаршу пользоваться LaTeX. Грамотный админ должен установить софт + тренинг на один рабочий день.

Другое, что для мощь LaTeX не нужна для тех документов, которые делает секретарша. Word обычно подходит (odt/sxw, один чёрт, подойдут), тем более что с ним проще.
Реальная проблема с LaTeX следующая (с ней сталкивался):
- я пишу документ для человека, но не могу его заставить поставить TeX (большой начальник :) )
- посылаю ему PDF
- он хочет в документе внести правки, а не судьба
- с Word'ом этого нет. Здесь просмотрщик == редактор
Вот-вот, я именно об этих проблемах и думаю. А конвертация из ТеХа в Word/RTF/... — это полумера.

P.S. А вроде в Acrobat Reader была функция комментирования... нет?
не в Reader :(

я с этой проблемой столкнулся когда диссер руководителю за границу посылал... потом пришлось 2 дня конвертить его в РТФ, а правки обратно в ТеХ агреггировать еще 3 дня :(
есть LyX визивиг редактор для LaTeX думаю секретарше самое то...
Я думаю это всё можно делать в wiki, но нужен вариант вывода результата в текстовый редактор.
Вики — это здорово, но что вы будете делать, если уже есть договорённости с партнёрами об обмене документами в ODF и PDF? Писать вики, предоставляющую весь необходимый функционал ODF, чтобы потом в него экспортировать? Т.е. это получается дополнительная внутренняя сущность. В моей модели лишних форматов не было (если не считать гипотетический XML diff). Лишний формат — лишние проблемы при перекодировании!
вики серьезные системы имеют экспорт, например, MediaWiki на которой работает википедия.
а зачем это все изобретать, когда есть Google Docs и куча других компаний, предоставляющая аналогичный функционал? там же есть и импорт/експорт в офисные форматы и множество фич, о которых у вас даже не упомянуто, но они нужны или облегчают работу.
Гугл не есть открытая технология, стало быть, и её весьма непросто использовать в локальной сети предприятия, не подключённой к Интернету.

Наконец, просто паранойя. Не хочется свои документы на серверах «потенциального противника» оставлять.
В принципе, в нашем отделе документирования так всё и происходит, разве что нет связи автоматической связи между СУЗ и СУВ (пользуясь вашей терминологией). Честно говоря, плохо представляю, как это можно удобно автоматизировать, в СУЗ придется выбирать как-то вписывать изначально файл, чтобы она следила за изменениями.. Обычно же, достаточно просто комментом в СУЗ написать ссылку на СУВ, на конкретный файл и все нормально.
Конечно, нормально. Для исходного кода программ мы именно так сейчас и делаем.

У Subversion есть post-commit-hook, через него можно как-то и автоматизировать... А вообще, есть же неоткрытые объединённые системы, управляющие сразу и исходниками, и заданиями. Тот же Google Code, например.
OpenOffice + O3Space Community Edition
или OpenOffice + NauDOC
- велосипед изобретаете :(
Спасибо за ссылки.

Судя по описанию на сайте, NauDOC — это совсем не то, что нам нужно, но все равно скачаю и посмотрю.
Присматривался я к NauDOC. Как то не очень дружелюбно показалось + вопрос как они к расширению/изменению функционала отнесуться.
- нет сервера под Linux;
- нет клиента под Linux;
- он же сцуко платный!
- на сайте Microsoft я что-то не нашёл толкового описания возможностей Sharepoint, но судя по опыту моего общения с MS Office, там никогда не было ничего похожего на diff, и соответственно, всей мощи управления версиями.

Итог: не подходит.
Было бы круто это все дело к открытой ERP привиньтить (Adempiere, OpenBravo). Мне кажется, что в этом случае продукт получит большее распространение.
В Word'е есть возможность сливать два файла в один утверждая (или отвергая) различия между ними. Плюс есть возможность сохранять разные версии одного документа в одном файле. Так что если еще и тезисно описывать изменения в новой версии документа, то для небольших групп с малым документооборотом вполне можно использовать.
По-моему, там это реализовано в таком страшном и неюзабельном виде, что повеситься можно.
UFO just landed and posted this here
Sign up to leave a comment.

Articles