Разработка технической документации и технические писатели Технические писатели и разработка технической документации технические писатели в Телеграм 

 obmen_soobsheniyami.png Чат для технических писателей 
 Зарегистрируйтесь
Страницы: 1 2 След.
RSS
Выбор системы разработки программной и технической документации, Есть требования к системе, нужна помощь с подбором ПО.
 
Нужна помощь пользователей форума в выборе системы разработки программной и технической документации (читал, похожие темы здесь, но набор требований там был другой, поэтому изучаю возможности разных систем и их комплектаций).

Дано

  1. На предприятии используются 2 программы для поддержки документации: H&M (лицензия) – для ПО, LaTeх (в виде TeXLive + TeXStudio) – для полного пакета документов по ГОСТу для большой номенклатуры «железа»;
  2. Команда: несколько разработчиков, один техпис (H&M знает хорошо, LaTeх – начальные знания достаточные для выпуска документов по ГОСТу), он же будет выполнять  управление системой. Уровень познаний техписа в программировании – написание автоматизированных тестов выше среднего уровня для ПО, Web-интефейсов (Selenium IDE, AutoIt), желание развиваться есть;
  3. Используемая ОС – Windows.
Требования к системе
  1. Принцип единого источника (желательно также, чтобы при изменении данных в источнике все связанные документы формировались бы автоматом или по одному-двум кликам);
  2. Единая система для всей документации (как можно меньше "костылей", которые будет трудно автоматизировать), может состоять из нескольких программных продуктов (подсистем);
  3. Легкий интерфейс для первичного редактирования текста, который будет выполняться разработчиками ПО, «железа» (желательно WYSIWYG-интерфейс, но не обязательно);
  4. Возможность компилирования документов в формате pdf по ГОСТу!!! (рамочки, штампики, нумерация элементов документов, корректное разбиение многостраничных  таблиц и т.д.) – не видел соответствующих шаблонов в H&M (нумерацию элементов использую);
  5. Возможность использования в тексте ссылок на элементы документа типа «см. рис.3, см. п. 1.1» с автоматическим изменением нумерации, а также гиперссылок (clickable);
  6. Конвертирование информации в форматы web-документов html, wiki (планируется создание базы знаний для клиентов на основе единого источника) и автоматическое обновление данной информации на сайте (в базе знаний);
  7. Возможность вызова контекстной справки (для chm, webbased);
  8. Поддержка перехода на другие языки единого источника (выпуск документации на другом языке).
Еще один вопрос
Специ по LaTex подскажите, можно ли прикрутить к нему недостающие возможности из указанных требований? Импортировать, при переходе на другую систему, придется много документов.
 
Вам надо решение out of box или готовы сами собрать из компонентов?
 
Готов сам собрать из компонентов.
Подходящий конвертер из LateX в html найден.
Изменено: H&M'альщик - 01.02.2016 10:12:22
 
На базе LaTeX систему, работающую по принципу единого источника, собрать вряд ли возможно. По принципиальным соображениям.

LaTeX это полный по Тьюрингу язык программирования, ориентированный на создание печатного представления научной информации (книг, статей и т.п.).

Он заточен на то, чтобы точно специфицировать и создавать печатное представление информации на листах бумаги заданного формата.

Тогда как принцип единого источника предполагает, что формат представления информации на разных носителях должен быть разный,

Например, на бумаге - одно представление, на мониторе большого формата - другое, на экране смартфона - третье.

И формат представления может динамически меняться - например, при изменении размера окна с текстом. Или при изменении ориентации смартфона/планшета.

Кроме того, в современной онлайн-документации часто применяются интерактивные элементы, типа Pop-up, togglers и др., которые в LaTeX не предусмотрены.

Можно сделать конверторы из подмножеств LaTeX в HTML, HTML5, CHM, формат Wiki, или Markdown. Кое-какие конверторы уже созданы энтузиастами.
Но это годится лишь для любительских нужд. Т.к. заметно увеличивает сложность и трудоемкость поддержки системы документации.
Профессиональные системы подготовки документации (Madcap Flare, Robohelp, Author-it и пр.) такие поделки не используют .  
Изменено: Виктор Фигурнов - 01.02.2016 11:20:51
 
Да я их смотрел, читал обзоры, сравнивал и т.д. Но дело в том, что оформление по ЕСКД (штампы, рамки) для нас получается в приоритете: в этих системах из коробки оформление по ЕСКД нет (я не нашел). А заново форматировать вручную по ЕСКД каждый уже созданный документ даже с применением уже подготовленных шаблонов затратно (на данный момент я не нашел простого способа).
Можно, конечно, сделать вот так, например HTML -> экспорт в *.tex (LateX) -> ручная правка -> pdf по ЕСКД, но боюсь затык по времени будет с ручной правкой каждого документа.
Вы пишите "И формат представления может динамически меняться - например, при изменении размера окна с текстом. Или при изменении ориентации смартфона/планшета" - Эта задача на данный момент не стоит и в ближайшем будущем ее нет. А вот "собирать" из разных файлов документ в LateX'e можно.
 
Отвечу по компонентам. Это лично мое мнение и с чем я работал.

Цифра - соответствует вашему списку.

1. Docbook или DITA (ниже говорю по docbook, т.к. я с ним тесно работаю и знаю, о чем речь). В связи с тем, что у вас Latex, то это значит НЕ topic-oriented изложение. Значит docbook. Впрочем, с выходом DocBook 5.1 грань между ним и DITA стирается.

2. Единая система чего? Хранения, сборки, авторинга, отображения?
- Хранение - SCM (svn, git)
- Сборка - либо offline (тогда Jenkins, Maven, Gradle).
- Авторинг - редатор типа XMLMind, OxygenXML
- Отображение - здесь зависит от ваших возможностей (либо скриптовые языки + prebuild сайт), либо Apache Cocoon (отображение в realtime - тогда не надо пункт "Сборка").

3. См. пункт Авторинг - там все это есть. Правда, требуется привыкнуть к принципам ввода текста (например, к тому, что по желанию нельзя заголовок сделать жирным или курсивом :)

4. В docbook - точно есть. М.б. требует небольшой допилки, но есть. См. http://www.techwriters.ru/forum/forum604/topic20108/

5. docbook - без проблем. Там, впрочем, можно настроить не только ссылки на документы, но и разные ссылки по типам документов, и т.п. - что только душа пожелает.

6. Да, есть все это. См. пункт 2 - отображение

7. Да, есть все это.

8. Пункт не понял. Имеется в виду перевод на другие языки (в смысле, локали?) Если да, то однозначно xml-based стандарты. Т.к. есть возможность цепочки xml > xliff > CAT и в обратную сторону.

Единственное, что п.2 (КРОМЕ авторинга) - лучше всего идут на unix системам. С виндой там сложновато будет.
Изменено: Текрайтер из Питера - 01.02.2016 16:21:19
 
Цитата
Текрайтер из Питера написал:
В связи с тем, что у вас Latex, то это значит НЕ topic-oriented изложение.
Ничто не мешает в LaTeX разделять текст на топики и включать их командами \input и \include.
Если надо - с такими возможностями параметризации и управления, которые Docbook и DITA не снились.
 
Цитата
Виктор Фигурнов написал:
Цитата
Текрайтер из Питера   написал:
В связи с тем, что у вас Latex, то это значит НЕ topic-oriented изложение.
Ничто не мешает в LaTeX разделять текст на топики и включать их командами \input и \include.
Если надо - с такими возможностями параметризации и управления, которые Docbook и DITA не снились.
Например? Мне было бы интересно услышать... Т.к. я сам не сталкивался.
 
Цитата
Виктор Фигурнов написал:
Цитата
Текрайтер из Питера   написал:
В связи с тем, что у вас Latex, то это значит НЕ topic-oriented изложение.
Ничто не мешает в LaTeX разделять текст на топики и включать их командами \input и \include.
Если надо - с такими возможностями параметризации и управления, которые Docbook и DITA не снились.
Именно так и делаем. В дополнение сразу включаем настройки ЕСКД (рамочки, штампики). Могу поделиться опытом.
 
Цитата
Текрайтер из Питера написал:
-- Если надо - с такими возможностями параметризации и управления, которые Docbook и DITA не снились.
Например? Мне было бы интересно услышать... Т.к. я сам не сталкивался.
Да любыми. LaTeX это полный по Тьюрингу язык программирования. Практически всё, что вы можете себе представить изображенным на бумаге, может быть выведено средствами LaTeX. Любые тексты, любые рисунки, любое оформление. Например, можно задать значения текстов надписей на круглой печати, и название файла рисунка, и топик LaTeX выведет изображение круглой печати с заданными надписями по кругу и заданным рисунком в центре. С помощью LaTeX можно по заданным данным вывести графики и диаграммы, в том числе 3-мерные графики, по ходам шахматной партии можно сгенерировать текст описания шахматной партии с картинками расположения шахматных фигур на доске в заданные моменты партии, и т. д., и т. п.
 
Цитата
H&M'альщик написал:
Да я их смотрел, читал обзоры, сравнивал и т.д. Но дело в том, что оформление по ЕСКД (штампы, рамки) для нас получается в приоритете: в этих системах из коробки оформление по ЕСКД нет (я не нашел).
Этого вы нигде не найдете. Все серьезные системы подготовки документации делаются в расчете на на мировой рынок, их разработчиков интересуют потребности массовых платежеспособных пользователей, прежде всего, пользователей США, Европы, Канады, Японии, Австралии, Китая, стран Юго-восточной Азии. Фирмы-разработчики вряд ли будут отвлекать свои ресурсы для обеспечения странных игр нескольких живущих в захолустье нанайских мальчиков в рамочки и штампики.

И потом, ЕСКД меняется - так, за 2012-2014 г. вступило в силу 25 новых и измененных стандартов ЕСКД. Кроме того, в России вводятся и меняются стандарты документации для других отраслей - для строительства, градостроительства, фармацевтики, для организационно-распорядительной документации. Все эти стандарты разные. Вы надеетесь, что найдется фирма-разработчик, которая будет отслеживать изменения в сотнях российских стандартов, а также в десятках тысяч аналогичных стандартов других стран, чтобы обеспечивать десятки тысяч разных шаблонов документации?

Мне кажется, что задача должна ставиться иначе - надо выяснить, можно ли в системе подготовки документации обеспечить нужно оформление, печатных и электронных документов насколько просто и удобно это делается, какие имеются ограничения, и исходя из этого принимать решение. По моему мнению, нужные рамки и штампики, требуемые форматы нумерации элементов документов, разбиения многостраничных таблиц и т.д. можно обеспечить во всех четырех существующих на рынке профессиональных системах подготовки технической документации — в Madcap Flare, Adobe Robohelp, Adobe Framemaker и Author-It.
 
Текрайтер из Питера написал:
4. В docbook - точно есть. М.б. требует небольшой допилки, но есть. См. http://www.techwriters.ru/forum/forum604/topic20108/Да есть глянул:настройки титульной, рамки, имена в штампиках есть. Примера только не нашел.
Текрайтер из Питера написал:
8.
Пункт не понял. Имеется в виду перевод на другие языки (в смысле,
локали?) Если да, то однозначно xml-based стандарты. Т.к. есть
возможность цепочки xml > xliff > CAT и в обратную сторону.
Да
именно локали. Многие используют для этого разные источники данных. В
LaTexe для этого можно использовать разные места хранения информации -
может быть есть более удобный подход
Изменено: H&M'альщик - 02.02.2016 10:30:42
 
Цитата
Виктор Фигурнов написал:
По моему мнению, нужные рамки и штампики, требуемые форматы нумерации элементов документов, разбиения многостраничных таблиц и т.д. можно обеспечить во всех четырех существующих на рынке профессиональных системах подготовки технической документации — в Madcap Flare, Adobe Robohelp, Adobe Framemaker и Author-It.
Как убедиться в возможности работы в соответствии с требованиями ЕСКД в этих системах без их глубокого изучения? Например по docbook я нашел шаблоны, по ссылке вашего коллеги. А в перечисленных вами системах (искал в Madcap Flare, Author-It) не нашел обсуждения даже на форумах (.
 
Цитата
H&M'альщик написал:
Текрайтер из Питера написал:
4. В docbook - точно есть. М.б. требует небольшой допилки, но есть. См.  http://www.techwriters.ru/forum/forum604/topic20108/ Да есть глянул:настройки титульной, рамки, имена в штампиках есть. Примера только не нашел.
Текрайтер из Питера написал:
8.
Пункт не понял. Имеется в виду перевод на другие языки (в смысле,
локали?) Если да, то однозначно xml-based стандарты. Т.к. есть
возможность цепочки xml > xliff > CAT и в обратную сторону.
Да
именно локали. Многие используют для этого разные источники данных. В
LaTexe для этого можно использовать разные места хранения информации -
может быть есть более удобный подход
4. Пример есть на битбакете. Делаете git clone и вперед :)

8. Ну здесь тоже можно использовать разные источники информации (если я вас правильно понял). Как по разным файлам, так и в одном через XInclude.
 
Цитата
Виктор Фигурнов написал:
Цитата
Текрайтер из Питера   написал:
-- Если надо - с такими возможностями параметризации и управления, которые Docbook и DITA не снились.
Например? Мне было бы интересно услышать... Т.к. я сам не сталкивался.
Да любыми. LaTeX это полный по Тьюрингу язык программирования. Практически всё, что вы можете себе представить изображенным на бумаге, может быть выведено средствами LaTeX. Любые тексты, любые рисунки, любое оформление. Например, можно задать значения текстов надписей на круглой печати, и название файла рисунка, и топик LaTeX выведет изображение круглой печати с заданными надписями по кругу и заданным рисунком в центре. С помощью LaTeX можно по заданным данным вывести графики и диаграммы, в том числе 3-мерные графики, по ходам шахматной партии можно сгенерировать текст описания шахматной партии с картинками расположения шахматных фигур на доске в заданные моменты партии, и т. д., и т. п.
Я согласен, что в смысле печатки  LaTeX вне конкуренции.

Имелось в виду другое - единый источник средствами  LaTeX, т.е.:
1. Diff|Merge.
2. CAT
3. Сборка по автомату из SCM с использованием CI.
Изменено: Текрайтер из Питера - 02.02.2016 11:41:07
 
Цитата
H&M'альщик написал:
Например по docbook я нашел шаблоны, по ссылке вашего коллеги. А в перечисленных вами системах (искал в Madcap Flare, Author-It) не нашел обсуждения даже на форумах (.
Обсуждаются проблемы. Когда задача решается без каких-либо проблем, нет повода для обсуждения.  hi-hi-hi

Вы ведь не сомневаетесь, что в LaTeX можно нарисовать любые рамочки, штампики или иные элементы оформления?
Думаю, не сомневаетесь. Потому что в LaTeX имеются механизмы, позволяющие нарисовать всё, что угодно.

Точно так же, в Madcap Flare, Author-It, Robohelp имеются механизмы, позволяющие задействовать любые элементы оформления печатных страниц и электронных документов.
 
Цитата
Текрайтер из Питера написал:
единый источник средствами  LaTeX, т.е.:
1. Diff|Merge.
2. CAT
3. Сборка по автомату из SCM с использованием CI.
Средства контроля версий, автоматического перевода и автоматической сборки это полезные возможности, но принцип единого источника - это совершенно иная концепция.
 
Цитата
Виктор Фигурнов написал:
Цитата
H&M'альщик   написал:
Например по docbook я нашел шаблоны, по ссылке вашего коллеги. А в перечисленных вами системах (искал в Madcap Flare, Author-It) не нашел обсуждения даже на форумах (.
Обсуждаются проблемы. Когда задача решается без каких-либо проблем, нет повода для обсуждения.  

Вы ведь не сомневаетесь, что в LaTeX можно нарисовать любые рамочки, штампики или иные элементы оформления?
Думаю, не сомневаетесь. Потому что в LaTeX  имеются механизмы, позволяющие  нарисовать всё, что угодно.

Точно так же,  в Madcap Flare, Author-It, Robohelp имеются механизмы, позволяющие задействовать любые элементы оформления печатных страниц и электронных документов.
1. Подскажите, какую из этих систем лучше начать изучать в первую очередь?
2. Madcap Flare, Author-It - не бесплатное ПО. Подскажите, можно ли в их демонстрационной версии "добраться" до элементов оформления типа рамок на страницах, "штампиков"? Хочу сначала убедиться, пощупать, изучить, до перехода.

По результатам моих обзоров и полученной здесь информации (спасибо всем, кто дает советы!) на данный момент получается вот такая картина:
1. внедрение на предприятии новой системы, которое включает перенос туда всех данных, ее настройка, обучение работы с ней разработчиков (система контроля версий) и одновременное ее изучение - не вариант.
2. исходя из п.1, принято решение о доработке существующей системы документации на основе LaTex-а, с одновременным изучением новой (какой - пока не выбрал), поэтому есть следующие вопросы
Цитата
Текрайтер из Питера написал:
Имелось в виду другое - единый источник средствами  LaTeX, т.е.:
1. Diff|Merge.
2. CAT
3. Сборка по автомату из SCM с использованием CI.
Подскажите, что под каждым из пунктов понимается и порядок работы с каждым из перечисленных средств?

Заранее благодарен!
 
Цитата
H&M'альщик написал:
1. Подскажите, какую из этих систем лучше начать изучать в первую очередь?
Любую. Мне больше нравится Flare, но это дело вкуса. Лаборатория Касперского работает на Author-It. Множество организаций работает на Robohelp, часто уже лет по 20 или более.

О популярности этих систем можно судить по опросам конференции технических писателей США WritersUA.
Там спрашивалось о важности различных программ для деятельности организации, в которой работает участник.
Шкала оценок:
1 = Unimportant
2 = Slightly important
3 = Moderately important
4 = Important
5 = Very important

Результаты (для наиболее известных систем подготовки документации):

MadCap Flare:   5 - 111 голосов, 4 - 15 голосов, 3 - 5 голосов, 2 - 6 голосов, 1 - 11 голосов
Adobe Framemaker: 5 - 99 голосов, 4 - 32 голоса, 3 - 24 голоса, 2 - 22 голоса, 1 - 22 голоса
Adobe Robohelp: 5 - 86 голосов, 4 - 11 голосов, 3 - 25 голосов, 2 - 25 голосов, 1 - 19 голосов
Author-it:      5 - 44 голоса, 4 - 5 голосов, 3 - 10 голосов, 2 - 8 голосов, 1 - 6 голосов

Остальные системы подготовки документации существенно отстают.

А почему-то популярные в России программки Help & Manual и Dr. Explain вообще не при делах:

Help & Manual:  5 - 4 голоса, 4 - 1 голос, 3 - 2 голоса, 2 - 4 голоса, 1 - 8 голосов
Dr. Explain:  5 - 0 голосов, 4 - 0 голосов, 3 - 2 голоса, 2 - 1 голос, 1 - 4 голоса

Цитата
H&M'альщик написал:
2. Madcap Flare, Author-It - не бесплатное ПО. Подскажите, можно ли в их демонстрационной версии "добраться" до элементов оформления типа рамок на страницах, "штампиков"? Хочу сначала убедиться, пощупать, изучить, до перехода.
Можно. У Robohelp и Author-It демо версии полностью функциональны, насколько я знаю, только ограничены по сроку работоспособности. У Flare демо версия добавляет в публикуемые (выходные) документы небольшое количество "шума" - лишние символы, перестановки символов и т.п. То есть, понять, что получится в результате, можно, а использовать демо версию для производства документации нельзя.
Изменено: Виктор Фигурнов - 08.02.2016 12:23:30
 
Цитата
H&M'альщик написал:

Цитата
Текрайтер из Питера   написал:
Имелось в виду другое - единый источник средствами  LaTeX, т.е.:
1. Diff|Merge.
2. CAT
3. Сборка по автомату из SCM с использованием CI.
Подскажите, что под каждым из пунктов понимается и порядок работы с каждым из перечисленных средств?

Заранее благодарен!

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

Поясню по каждому пункту на пальцах.

1. Diff|Merge - сравнение изменений и слияние между версиями. Типичная ситуация: у вас продукт версии 1.1, вы выпускаете 1.2, но вдруг обнаруживается ошибка в продукте (допустим, т.н. critical bug fix). Разработчики делают исправление, которое входит в версию 1.2.1. НО! При этом оно входит и в 1.1.1 - т.е. две ветки продукта существуют параллельно. Фактически вам, как разработчику ТД надо сделать 2 исправления то, которое станет 1.2.1, но и то, которое будет 1.1.1. Кроме того, это все включается в текущий trunk (ну или dev ветку, кто как называет). С использованием xml-based single sourcing - это делается просто. Ибо исходник - просто код. Как делается в ворде и HAT продуктах (Flare  и т.п.) - вы понимаете.
Подумайте, делали ли вы хоть однажды подобное в latex. Если нет, то этот пункт вас обходит стороной :)

2.  CAT - системы автоматизированного перевода - computer aided translation . Не буду лукавить, я НЕ знаю, как делается перевод в HAT, кроме как руками (Framemaker с внутренностями DITA к этому не относится). С использованием xml-based single sourcing: xml > xlf > CAT > xlf > xml. В идеале все делается автоматически. Если у вас нет перевода и не предвидится, то можете просто забыть об этом пункте :)

3. CI - системы непрерывной сборки - continuous integration. Они нужны, чтобы собрать в единое целое все, что хранится в SCM (source code management) или VCS (version control system). Т.е. в обычных HAT делается так: вы что-то исправили, нажали кнопочку и у вас на выходе готовый формат. С использованием xml-based single sourcing вы исправляете исходник, делаете commit и он уже пересобирается автоматически по требуемой логике внутри CI. Работа идет, как с исходником. Т.е. тот пункт нужен, чтобы работали предыдущие 2 пункта и также другие пункты, здесь не упомянутые.

Вывод: если у вас один продукта, который имеет 1 (максимум 2) варианта вывода можете не читать все, что здесь написано.

Все, что здесь написано имеет смысл только, если у вас:
1. Много продуктов.
2. Несколько языковых версий.
3. Поддержка нескольких веток одновременно.
4. Поддержка вариантивности веток (т.е. компании A - документация F, а компании Б - документация FGE).
5. Интеграция со сторонними продуктами (например, у вас есть Jira и вы хотите делать release notes не руками, а автоматически из нее и рассылать всем клиентам письмо со ссылкой на relnotes, в котором написаны только значащие для данного клиента изменения). Такая штука с использованием  xml-based single sourcing реализуется дня за 3.
Изменено: Текрайтер из Питера - 09.02.2016 14:01:08
 
Цитата
Текрайтер из Питера написал:
Ибо исходник - просто код. Как делается в ворде и HAT продуктах (Flare  и т.п.) - вы понимаете.
Как раз во Flare все исходники - это обычные текстовые файлы:
  • топики это простенькие XHTML-файлы,
  • стили это CSS-файлы.
  • оглавления, глоссарии, мастер-страницы, проекты и т.п.- это несложные XML-файлы
 
Цитата
Виктор Фигурнов написал:
Цитата
Текрайтер из Питера   написал:
Ибо исходник - просто код. Как делается в ворде и HAT продуктах (Flare  и т.п.) - вы понимаете.
Как раз во Flare все исходники - это обычные текстовые файлы:
 топики это простенькие XHTML-файлы,
 стили это CSS-файлы.
 оглавления, глоссарии, мастер-страницы, проекты и т.п.- это несложные XML-файлы
 
Понятно, я не был в курсе этого. Однако, это не отменяет сложности Diff|Merge на уровне файлов. Ибо, насколько я понял, при изменении (merge) заголовка в XTHML придется менять (руками)  "оглавления, глоссарии, мастер-страницы, проекты и т.п.- это несложные XML-файлы".

Еще один вариант - делать Diff каталога со всем этим хозяйством. А это вообще за гранью :)
Изменено: Текрайтер из Питера - 09.02.2016 14:25:31
 
Цитата
Текрайтер из Питера написал:
насколько я понял, при изменении (merge) заголовка в XTHML придется менять (руками) "оглавления, глоссарии, мастер-страницы, проекты и т.п.- это несложные XML-файлы".
Не придется ничего менять. Заголовок XTHML-файла в простейшем случае такой:
Цитата

    <?xml version="1.0" encoding="utf-8"?>
    <html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" xml:lang="ru">
        <head><title></title>
   </head>
А если использовать собственные стили и js-скрипты для топика - то чуть сложнее:
Цитата

    <?xml version="1.0" encoding="utf-8"?>
    <html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" xml:lang="ru">
        <head><title></title>
            <link href="../Resources/Stylesheets/mystyle.css" rel="stylesheet" />
            <script src="../Resources/Stylesheets/mystyle.js" type="text/javascript" />
   </head>
Менять этот код нужно очень редко, и его смена вообще никак не влияет на оглавления, глоссарии, мастер-страницы, проекты, стили.
Изменено: Виктор Фигурнов - 09.02.2016 16:19:45
 
Цитата
Виктор Фигурнов написал:
Цитата
Текрайтер из Питера   написал:
насколько я понял, при изменении (merge) заголовка в XTHML придется менять (руками) "оглавления, глоссарии, мастер-страницы, проекты и т.п.- это несложные XML-файлы".
Не придется ничего менять. Заголовок XTHML-файла в простейшем случае такой:
нет, я не об этом. Я не о header в xhtml, а именно заголовок в смысле title.

О чем я:
1. Вы изменяете заголовок, например, с "Структура программы" на "Структура системы".
2. Насколько я понимаю, оглавление динамически изменяется только при использовании GUI. Т.е. в оглавлении (если НЕ использовать GUI) останется "Структура программы"
3. Это все лежит в системе контроля версий. Получится нестыковочка.

Иными словами, чтобы сделать п.1 недостаточно просто его сделать, надо еще менять что-то руками (например, открывать файлы оглавления|проекта в GUI > оно там проапдейтится и т.д.). М.б., конечно, я не прав.
 
Цитата
Текрайтер из Питера написал:
Я не о header в xhtml, а именно заголовок в смысле title.
Как вы могли заметить, в приведенных мной примерах заголовок Title  пустой: <title></title> Это не случайно.

Цитата
Текрайтер из Питера написал:
Насколько я понимаю, оглавление динамически изменяется только при использовании GUI.
Это не так. Во Flare совершенно другая концепция оглавлений, чем та, к которой вы привыкли. Более сложная.
Во Flare можно создавать оглавления автоматически. Можно вручную. Можно создавать title для топика по оглавлению.
Можно использовать несколько оглавлений в одном проекте. Все зависит от задач. Оглавления бывают разных типов.. И т.д.

Описание использования оглавлений во Flare - 184 страницы
http://docs.madcapsoftware.com/FlareV11/FlareTablesOfContentsGuide.pdf
 
Страницы: 1 2 След.
Читают тему