Как стать автором
Обновить

Комментарии 241

«Пришлите пожалуйста все то же самое, но в формате Word»

Скриншотом в ворде, конечно же :)

Иногда, приходя утром в маленькую типографию, и видя очередь перед собой, я просто брал бумажку и писал на ней - "DFLT-COL SRA3 + Cut + Bend". Сотрудники сами выхватывали меня из очереди и я уходил одним из первых.

А можно, пожалуйста, расшифровку для непросвещённых?)

Уж простите за картинку.

Ну, я в целом-то понял, что смысл примерно такой) мне интересно, что конкретно это значит)

Выбрать цветовой профиль в меню (Default Color Management Settings) DFLT-COL SRA3 ( на формате бумаги SRA3 (320 x 450 мм))
Тираж обрезать (по меткам в макете) и согнуть.

Ага, все так. Иногда приходилось пользоваться тайнописью, которую понимал только сотрудник, что бы сэкономить время себе и нервы ему. Никому же не охота бегать от компа к принтеру, пытаясь сделать синий менее зелёным, а серый менее синим.

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

Я в тот момент просто жил в маленьком европейском городе, который раз в 10 больше, чем тот где я живу сейчас... но не суть. По дороге в офис у меня было всего 2 типографии, где приемщику не приходилось рассказывать о том, что такое SRA3. Да, в маленьких городках свои приколы.

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

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

yyy: Вообще приходить в первый раз в магазин радиодеталей страшнее, чем первый раз презервативы купить по-моему. Приходишь и так шепотом "мне бы конденсатор на 22Мф", тебя громко спрашивают "какой? Электролит? Тантал? Выводной? SMD?", ты "я не знаааааю" и все оборачиваются сразу, смотрят на тебя осуждающе и пальцами тычут.

(отсюда)

Это ещё ладно, я как-то раз стоял в очереди в магазине радиодеталей, ко мне подошёл какой-то чел, попросил подсказать, что за микросхема? И при этом показал фотку этой самой микросхемы, но с видом небольшого куска платы сверху, где маркировки, разумеется, видно не было. То, что он показал, было похоже на автомагнитолу, а микруха была похожа на tda2003, что я ему и сказал. Сейчас вспомнил, стало даже интересно, чем дело кончилось?

Сотрудники сами выхватывали меня из очереди и я уходил одним из первых

А я просто заливал PS на FTP типографии и никогда ничего не ждал

Я как-то деловую встречу на одном заводе, что близ остановки «Фабрика игрушек», начал с фразы «Нравятся мне ваши игрушки, особенно 48Н6».

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

Так я тоже брошюры печатал для того, чтобы их давать лично в руки каждому участнику во время встречи (продажи). Просто обычно все открывают презу в ppt и начинают рассказывать 60 слайдов "о компании", а я по мере рассказа просто брал из стопки часть брошюр и раздавал их продолжая рассказ. Потом брал следующую часть. Таким образом я отстраивался от всех своих конкурентов. Ну, и спустя полгода, возвращаясь к тому же клиенту я почти всегда видел свои брошюры либо аккуратно сложенными в стопочку, либо лежащими в зоне обитания сотрудников, а ppt-шки все обычно просто удаляют спустя некоторое время и мало кто их открывает второй раз.

Не, я чисто про то, что начатая с нескольких правильных слов беседа часто приводит к совершенно иному течению разговора, и эти слова для каждого клиента свои. Что «DFLT-COL SRA3 + Cut + Bend» вместо «мне тут лифлетик надо...», что 48Н6 вместо «ой, а это вы С-300 делаете?!».

Регулярно получаю скидку в оперативной полиграфии за ТЗ, сразу понятное технологу и верстальщику, а также за готовый к печати файл. Типа "Заказ на визитки: 50х90, 500 шт., матовая меловка 350 гр, 4+0, всё в CMYK, сделан вылет под обрез +2 мм, всё в кривых, overprint black, Corel15 как любит ваша сеть салонов :)"

А Word какой версии нужен?

Прекрасно! Просто гимн текстам и текстовым файлам ))

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

А второй любимой игрушкой был папин магнитофон-диктофон «Легенда-404». Но это – «уже совсем другая история» ))

Встал в 6 утра, чтоб плюсануть! :-) Отличная машинка! Тоже когда-то отец подарил, но я по глупой молодости оставил свой в университете, когда заканчивал. Этой зимой купил себе новый. Начал оцифровывать кассеты: даже у плёнок 30-летней давности шикарный звук, не понадобилось давить шум. А ещё у меня не было к нему блока питания и я использовал лабораторный ИП. Вы задумывались, сколько он ест во время работы? Меньше 1Вт! На 9В ток в районе 90мА!

Ещё бы родной микрофон к нему найти.

Приветствую, коллега по ностальгии! )

Я бы на Легенде всё ж не цифровал, ведь это один из самых первых советских кассетников, там качество звука хреновенькое. Надо брать японскую деку из 90-х. А насчёт микрофона - зайдите на сайт Мешок, там просто наберите 'Микрофон' и с большой вероятностью найдёте. На Мешке большая заточенность на советские изделия (в отличие от Авито, где по запросу "микрофон" вывалит кучу новодела из Китая), а ассортимент советских микрофонов не особо велик.

Ну, видимо, я не настолько аудиофил. Мой слух никаких огрехов не замечает.

https://disk.yandex.ru/d/uxXxVAwy762msw

Тем более цифрую больше, для проформы. Исключительно, чтобы высвободить носители для купленного зимой Commodore.

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

Так ФОРМАТ же, где УНИВЕРСАЛЬНОСТЬ, он же В БЛОКНОТЕ не откроется с форматированием

Есть commonmark. Не без проблем, но автору с его минимализмом должно базовых фич, которые везде работают, хватать

Непонятно, почему reStructuredText не взлетел — как по мне, его правила логичнее, из коробки поддерживается больше конструкций оформления, плюс авторы специально подумали над возможными точками расширения разметки (в Markdown все лепят кто во что горазд — отсюда и зоопарк).

RST придумали безумцы. Абсолютно нелогичная система разметки. Каждый раз, как надо было что-то на нём написать, плевался и ругался матом. Даже спустя несколько лет передёргивает от одного названия.

AsciiDoc хорош. Похож на MD, но богаче по возможностям, и в то же время чем-то проще и логичнее. Гораздо меньше бардака в спецификациях (можно считать, что спека одна). И в то же время в обычном редакторе по-прежнему выглядит как plain text.

Что такого безумного в rst? Где вы там нелогичность увидели?! Ссылки, изображения, сноски и ссылки на цитаты — все в едином, понятном, предсказуемом стиле, внятные правила взаимодействия знаков препинания с разметкой, возможность выделения частей текста специальным стилем помимо стандартной троицы жирный/курсив/моноширинный, на которые свою семантику навесить можно, единый механизм навешивания практически любых атрибутов блокам текста, адекватная поддержка таблиц аж в двух стилях (+ эмуляция через списки). Сравните с Markdown, где шаг влево-вправо и уже что-то где-то не работает или работает по-разному в разных реализациях (потому что нет единого общепринятого стандарта).

Начну с того, что всё это в значительной степени вкусовщина. Я понимаю и принимаю тот факт, что многим людям rst удобен и приятен в работе. Если они получают удовольствие от работы с этой системой разметки, это отлично. Ниже я перечислю те моменты, которые напрягали в своё время лично меня. Это не значит, что они обязательно должны напрягать всех. Это не значит, что с ними невозможно редактировать текст. К ним, я уверен, вполне даже можно привыкнуть. Другой вопрос в том, что если этот процесс привыкания проходит через боль, он пойдёт медленнее и тяжелее, чем если бы боли не было. Поэтому в своих проектах я старался rst избегать, а чужих проектов, где с ним приходилось работать, мне, к счастью, попадалось буквально 1-2.

Открываем документацию и начинаем идти по ней сверху вниз. Веселье начинается с самых же заголовков. Для каждого уровня заголовков используются свои символы. Какова логика выбора именно этих символов? Неизвестно, надо тупо их запоминать. Что, если надо добавить ещё один уровень вложенности? Непонятно. Зачем обязательно делать отбивку на всю длину текста? Не объясняют, но сама по себе необходимость банально бесит. Если я поменял текст заголовка, то практически наверняка придётся менять длину отбивки. Если я решил поменять уровень, то придётся полностью перебивать строку тупыми символами. В Markdown и AsciiDoc эти вещи сделаны намного логичнее.

Заголовок 1 уровня в RST
========================

Заголовок 2 уровня в RST
------------------------

Заголовок 3 уровня в RST
~~~~~~~~~~~~~~~~~~~~~~~~

Заголовок 4 уровня в RST
""""""""""""""""""""""""

# Заголовок 1 уровня в MD

## Заголовок 2 уровня в MD

### Заголовок 3 уровня в MD

= Заголовок 1 уровня в adoc

== Заголовок 2 уровня в adoc

=== Заголовок 3 уровня в adoc

Нелогичные и бессистемные способы обозначения внутренних команд и структур. Где-то используется :команда:, где-то .. команда::, где-то |палки|, в каких-то местах ещё добавляется бекслеш. Где разум, где логика? Всё приходится тупо зубрить.

Ссылки - это просто тихий ужас. Количество специальных символов и правил, которое требуется соблюсти для правильного форматирования, явно больше, чем в MD или Adoc. Зачем делать так сложно?

1. Внешние ссылки выглядят так: ссылка_.

.. _ссылка: http://librerussia.blogspot.ru/

2. Если несколько слов, тогда так: `ссылка в несколько слов`_.

.. _`ссылка в несколько слов`: http://librerussia.blogspot.ru/

3. `Более компактная запись ссылок <http://librerussia.blogspot.ru/>`_

Знак подчёркивания, две обычные точки, двоеточие, бектики, угловые скобки - это явный переизбыток. "Единый, предсказуемый стиль" - Вы это серьёзно? Сравниваем с:

[Ссылка в Markdown](https://example.com)

https://example.com[Ссылка в AsciiDoc]

Где-то тут должна быть картинка с Хаби Лейм.

Блоки исходного кода, у которых нет завершения, Карл! Если повезёт, код вставится правильно, а если не повезёт - ну штош, придумывай костыли. С питоном, помнится, особенно весело бывало. Таблицы с обязательными отступами, блин. Вот мне прям делать нечего в текстовом редакторе, кроме как пробелы и значки отбивать!

Я уже задолбался. Смотрю в их спеку и чувствую, как у меня снова поднимается давление. Это и правда плохой язык разметки. Он плох тем, что требует от человека соблюдать кучу каких-то совершенно необязательных правил (всевозможные отступы, разнообразные спецсимволы, ручные отбивки спецсимволами и т.п.). Посмотрите для сравнения на правила AsciiDoc, они намного проще и не требуют всей этой тупой обязаловки.

Ещё про таблицы. Периодически приходится делать таблицы с достаточно большими объёмами текста внутри. Не 1-2 слова, как в туториале, а несколько полноценных предложений. И при этом хочется, чтобы изменение текста в одной ячейке не приводило к необходимости подстраивать под изменения все остальные ячейки. С этой точки зрения, таблицы в RST полный отстой:

.. table:: Заголовок таблицы (Внимание! Отступ таблицы относительно
           команды ..``table::`` обязателен)

    +------------------------+------------+----------+----------+
    | Header row, column 1   | Header 2   | Header 3 | Header 4 |
    | (header rows optional) |            |          |          |
    +========================+============+==========+==========+
    | body row 1, column 1   | column 2   | column 3 | column 4 |
    +------------------------+------------+----------+----------+
    | body row 2             | Cells may span columns.          |
    +------------------------+------------+---------------------+
    | body row 3             | Cells may  | - Table cells       |
    +------------------------+ span rows. | - contain           |
    | body row 4             |            | - body elements.    |
    +------------------------+------------+---------------------+

Вот меняю я их column 2 на column 2, row 1. Что надо поменять в таблице? Или увеличивать по ширине всю вторую колонку (а с ней и таблицу в целом) - это изменение 12 строчек текста (в основном, отбивка и пробелы). Или впихивать текст в новую строчку (так везёт не всегда) - это изменение 1 строчки и добавление новой. Такие вещи должен делать не человек, а машина. Получается, что нормально редактировать таблицы в RST можно только с поддержкой специализированного редактора или IDE. Что же это за текстовый формат такой? С системами контроля версий такой подход тоже дружит плохо.

В Markdown таблицы не сильно лучше - их нет в изначальной спеке, а расширения добавляют таблицы примерно в подобном же стиле. Можно ещё использовать встроенный HTML, и это порой выручает. Хотя бы можно отделить контент от представления:

<tr>
<td>
Текст ячейки можно написать в отдельной строчке, и это не повредит всем остальным строчкам.
</td>
<td>
Другая ячейка
</td>
</tr>

В AsciiDoc используется максимально адекватный формат из известных мне:

|===
| Header row, column 1 | Header 2 | Header 3 | Header 4

| body row 1, column 1
| column 2
| column 3
| column 4

| body row 2
...
|===

Отступы опциональны (я обычно делаю их для себя, чтобы визуально отделять строки в текстовом представлении). Каждая ячейка может содержать сколько угодно текста, и это не помешает остальным. Накладные расходы на оформление структуры обычно минимальны - одна палка на ячейку, плюс |=== для обозначения начала и конца таблицы. Если нужно заморочиться спанами и нестандартной шириной колонок, это тоже можно сделать (но лично мне такое нужно редко, в 99% случаев использую обычные таблицы без наворотов).

О.. Я когда выбирал между md и adoc для формата личных записей то формат таблиц был одним из весомых аргументов - adoc поддерживает тот же формат что и в файлах используется - csv, tsv. Копипастить между разными программами одно удовольствие - всё работает из коробки. Единственный минус - в tsv если в конце пустые значения то idea по умолчанию их обрезает при вставке и нормально с этим работает, но в таблицах adoc эти значения заменяются значениями со следующей строки. Но это не совсем баг а более строгое следование спецификации. (У них это даже в доке написано)

В AsciiDoc используется максимально адекватный формат из известных мне

С одной стороны да, но с другой... Там, например, нет возможности объединить ячейки. А иногда бывает нужно...

Спасибо! Не знал. Когда-то понадобилось - искал в документации, не нашел.

Буду знать теперь.

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

Для каждого уровня заголовков используются свои символы. Какова логика выбора именно этих символов? Неизвестно, надо тупо их запоминать.

Читаем внимательнее. Да, к сожалению, конкретно в этой ссылке переведено немного неправильно. На официальном сайте написано корректнее. Ничего запоминать не нужно. На каждый уровень — свой символ. Причём уровень определяет по первому использованию. Нравится, чтобы первым уровнем были дефисы (-) — начинайте с дефисов. Хотите знаки равно (=) — начинайте со знаков равно. Всё просто. Отбивка на всю длину (опять не так, не на всю, а не короче заголовка) нужна для устранения неоднозначности с горизонтальной чертой-разделителем. Заголовки в стиле Markdown конечно, компактнее, но как по мне, они значительно хуже заметны в тексте.


Нелогичные и бессистемные способы обозначения внутренних команд и структур.

Всё логично. :команда: для строчной разметки. .. директива:: — это так называемые директивы для объявления специальный сущностей. Заметьте, сущности могут быть любыми, но все они описываются в едином стиле. |палки| — для подстановок (aka замен), когда надо какое-нибудь сложное форматирование нагородить, например.


Ссылки — это просто тихий ужас.

В корне не согласен. Как раз в reStructuredText самая удобная работа со ссылками. Не обязательно пихать саму ссылку в текст (она может быть длинной и некрасивой), можно просто пометить слово или группу слов здесь ссылка_, а ниже дать расшифровку


.. _ссылка: https://www.google.ru/search?q=краткий+синтаксис+ссылок+в+markdown&newwindow=1&ei=ta07ZNzRDpCGwPAPusOCsAE&ved=0ahUKEwicgMv6-a3-AhUQAxAIHbqhABYQ4dUDCA4&uact=5&oq=краткий+синтаксис+ссылок+в+markdown&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIFCAAQogQyBQgAEKIEMgUIABCiBDoKCAAQRxDWBBCwAzoHCAAQDRCABEoECEEYAFCUJVjHZGCqZ2gDcAF4AIABdIgB5RCSAQQ2LjE1mAEAoAEBoAECyAEIwAEB&sclient=gws-wiz-serp

В Markdown у вас есть единственный вариант — [ссылка](https://www.google.ru/search?q=краткий+синтаксис+ссылок+в+markdown&newwindow=1&ei=ta07ZNzRDpCGwPAPusOCsAE&ved=0ahUKEwicgMv6-a3-AhUQAxAIHbqhABYQ4dUDCA4&uact=5&oq=краткий+синтаксис+ссылок+в+markdown&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIFCAAQogQyBQgAEKIEMgUIABCiBDoKCAAQRxDWBBCwAzoHCAAQDRCABEoECEEYAFCUJVjHZGCqZ2gDcAF4AIABdIgB5RCSAQQ2LjE1mAEAoAEBoAECyAEIwAEB&sclient=gws-wiz-serp). Бгг… Ужас.


Также, мне решительно непонятно, в чём проблема понять, что полный синтаксис `ссылка на несколько слов`_, но если слово одно, то обратные кавычки можно опустить и писать просто вот так_. Ну а если ссылка короткая, у вас есть возможность её сразу по месту в текст и упихнуть:


`Пройдёмте в гугол? <www.google.ru>`_

А особено мне в Markdown не нравится выбранные символы для обрамления ссылок. Квадратные скобки, мать вашу! Одни из самых часто используемых символов просто вот так взяли, и выкинули из обращения. Выбор reStructuredText для этой цели обратных кавычек гораздо более удачный вариант.


Таблицы с обязательными отступами, блин.

Это только внутри директивы .. table:: (заметьте, это общее правило, касающееся директив, а не конкретно вот тут для таблиц придумали). Не нужна вам подпись к таблице, не вкладывайте её в директиву, она просто даёт больше гибкости (опять стандартным для разметки образом!) — заголовок к таблице указать, например, или какие-то её свойства.


Ещё про таблицы.

Используйте простые таблицы, их придумали специально на такой случай!


===  ==============
#    Заголовок
===  ==============
1    какой-то текст
2
...
n
===  ==============

Кроме того, есть встроенная директива .. list-table::, позволяющая на рендере делать таблицу из списков при необходимости. Сравните с вашим примером AsciiDoc, где нагородили ещё один целый отдельный формат для этого. Не говоря уже о том, что в исходнике таблица уже не выглядит, как таблица. Ну и зачем нужен такой язык разметки, когда проще в HTML тогда сразу всё насовать, раз без браузера всё равно не посмотреть?

В AsciiDoc по умолчанию таблица не выглядит как таблица - полностью согласен, но стоит добавить слово csv или tsv или вообще сказать что вот разделитель например |, то уже таблица не просто выглядит как таблица а прям обычный csv/tsv файл - можно вставлять откуда хочешь (например sql develover в tsv копирует) или просто в файл перенести as is. Я немного изучал это и пришёл к выводу что в asciidoc наиболее user friendly таблицы - для остальных языков разметки нужно обязательно что то своё использовать.

Вы спросили, почему RST не популярен - я ответил, какие боли возникали с ним лично у меня. Уверен, подобные проблемы испытывали и многие другие люди - и в том состоит возможный ответ на Ваш вопрос. Бессмысленно и бесполезно расписывать "используйте Y вместо X". Я всё равно не буду использовать RST без жесточайшей необходимости, когда есть прекрасный AsciiDoc. Не вижу смысла продолжать дискуссию в подобном ключе. Каждый выбирает инструмент, который лично ему удобнее, и это хорошо. Но формата, удобного абсолютно для каждого, в природе не существует.

(https://www.google.ru/search?q=краткий+синтаксис+ссылок+в+markdown&newwindow=1&ei=ta07ZNzRDpCGwPAPusOCsAE&ved=0ahUKEwicgMv6-a3-AhUQAxAIHbqhABYQ4dUDCA4&uact=5&oq=краткий+синтаксис+ссылок+в+markdown&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIFCAAQogQyBQgAEKIEMgUIABCiBDoKCAAQRxDWBBCwAzoHCAAQDRCABEoECEEYAFCUJVjHZGCqZ2gDcAF4AIABdIgB5RCSAQQ2LjE1mAEAoAEBoAECyAEIwAEB&sclient=gws-wiz-serp).
Бгг… Ужас.

Я бы даже сказал "ужас-ужас", потому что правильно сделать вот так: https://www.google.ru/search?q=краткий+синтаксис+ссылок+в+markdown


Без этой тонны браузероспецифичного мусора

Тут главное принцип.

В Markdown у вас есть единственный вариант

Text [title][ref] more text

[ref]: http://localhost "additional info"

Text title more text

См https://daringfireball.net/projects/markdown/syntax#link.

~То что хабр не научился в этот формат -- другой вопрос.~ Он вполне общепринятый и вне md-мирка

P.S. хабр умеет, но только строго с кавычками в additional info

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

Похоже, это относительно недавнее дополнение к формату

Года 2000-2004. Это сайт автора формата markdown с его оригинальным конвертером на перле. Есть ещё дуальная утилита html2text происхождением из тех же времён.

Но здесь мне не нравится синтаксис с квадратными скобками и для заголовка ссылки, и для идентификатора. Особенно смущает пункт, что они могу разделяться пробелом. Вот зачем?!

Общепринятый формат для цитирования (имея ввиду бумажные книги и статьи), когда в ref'ы стали помещать ссылки. Привычный многим десятки лет (не знаю использовали ли его в эхах, но в списках рассылок видел очень давно. Так что скорее вопрос "почему бы и нет?"

А каким редактором пользуетесь для написания доков в AsciiDoc?

Я пользуюсь AsciiDocFX для создания общей структуры документа, а потом уже редактировать можно и в VSCode (есть плагин AsciiDoc с возможностью превью).

Я использую vim для всего, в том числе для AsciiDoc. Мне кажется, этот формат подерживают все популярные редакторы и IDE.

когда-то давно выбирал замену для Markdown и остановился на AsciiDoc - он "близок" к Markdown, так же легко читается/пишется, некоторые "скриптования" уже встроены в синтаксис

Мне тоже AsciiDoc понравился. Я тоже попробовал весь свой текст в AsciiDoc писать. Получается хорошо, когда на выходе нужно получить манускрипт с хорошей типографикой в ps или pdf. А вот чтобы отрендерить в статью на хабр (вы ведь их пишите) не нашёл шаблона ни для ascidoctor ни для pandoc.

А каким редактором пользуетесь для написания доков в AsciiDoc?

В этой статье используются списки, жирный шрифт и цитата

И второй список отформатирован в другом стиле

Почему эта статья написана не без форматирования?)

Форматирование из файла не скопировалось

Простые текстовые файлы безо всякого форматирования много лет остаются
на вершине моего личного хит-парада способов хранения информации

+1, текст статьи как будто про меня. (на половину)

Универсальность. Текстовый файл можно открыть почти на любом устройстве

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

Устойчивость. .....в худшем случае потеряете несколько слов.

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

Избыточность. Формально текстовые файлы обладают избыточной информационной энтропией

стоит ли думать об этом, когда фотка весит 15 мегабайт,
а текст пару сотен килобайт....
при современных HDD, можно всю жизнь печатать,
хранить в 10 копиях, и всё равно не заполнить 20 ТБ накопитель.

Неструктурированность. Все символы в текстовом файле равнозначны — текст он и есть текст. Тут нельзя атрибутировать блоки

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

Hidden text

но если храните пароли, советую строку с паролем просто
продублировать 2-3 раза, помимо ошибок аппаратных,

Один бэд блок и ваши 2-3 раза не помогут. Или о каких аппаратных ошибках вы говорите?

бед блок грохнет 4 кб, не знаю как у остальных,
буду опираться на свой случай,
файл с паролями весит примерно 200кб,
и хранится в одной папке примерно 10 штук копий,
а папка продублирована на несколько жестаков.
один бед блок сломает один файл,
после чего откроется запасная копия и нужный фрагмент
будет прочитан.
но если память не ECC, то возможны битовые ошибки
ещё на моменте редактирования и сохранения,
и работы с дисковым кэшом, и при копировании.

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

дак вроде ведь никто не призывает отказываться от всего этого,
и вроде никто не обесценивает менеджеры паролей,
тут речь о том что файл откроется хоть на андроиде,
хоть на динозавре сименс, SX65, на котором по молодости
я читал книги, сохранив их кусочками в текстовом файле.
а по теме шифрования я тоже не вижу проблем,
если файл хранится на ПК то жестак шифрованный целиком,
если файл надо таскать на КПК, то 7z архив с паролем.

https://siemensgsm.ru/foto/cx65_02.jpg

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

в удобном облачном хранилище паролей - надежно, прогрессивно, безопасно.

...ровно до тех пор, пока облачное хранилище не посетили { маски-шоу | красный петух | Челябинский метеорит | Анатолий Чубайс | вписать вариант }.

НЛО прилетело и опубликовало эту надпись здесь

Ни разу часть изменений в базе не теряли после удачной синхронизации при модификации в двух источниках?

НЛО прилетело и опубликовало эту надпись здесь

Я ловил это сидя один на двух устройствах не одновременно, проблемы с синхронизацией на одном из них -- и можно не заметить как копии разъехались

НЛО прилетело и опубликовало эту надпись здесь

Так там тогда появляется "конфликтная копия бла бла" кажется можно синкнуться и с ней тоже.

Стандартизованность.

Разные кодировки, наличие/отсутствие BOM для юникода, разные переводы строки: \n \n\r

Размер.

Юникод для кириллицы увеличивает раза в два размер файлов.

Юникод для кириллицы увеличивает раза в два размер файлов.

Это имеет хоть какую-то важность разве?

Оскорбляет внутреннего минималиста же. Пункт 4 — размер.

А json, бегающий на этом сайте с комментариями вместо бинарного протокола его не оскорбляет? А приложения по 100мб на телефоне не оскорбляют? Нет, конечно, надо тошнить именно на юникод.

Размер файлов имеет значение для тех, кто платит за жёсткий диск.

Платит. За жесткий диск. Что за чушь?
Даже если допустить что, вы ужасный графоман и пишите аж 50кб текста в день. 5036580=1,5гб на всю жизнь. Насколько будет дороже хранить данные, если их станет не полтора гб, а три? Ни на сколько, потому что найти какое-то хранилище сейчас, куда бы не поместилось полтора гигабайта, наверное, невозможно.

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

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

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

Вы когда-нибудь на своём компьютере запускали любой анализатор размера файлов типа WinDirStat или Sequoia View? Попробуйте как-нибудь, узнаете, что тексты к расходу места имеют весьма малое отношение.

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

"Но ведь пять старушек — уже рубль!" (c)

НЛО прилетело и опубликовало эту надпись здесь
\n\r

У вас комментарий битый, правильная последовательность — \r\n.

Или это просто путешественник из времени, где майкрософт опять что-то несовместимо «улучшила» :D

Можно пошаманить с раскладкой клавиатуры, чтобы при наборе текста вместо русских букв везде где можно писались английские эквиваленты, например a, e, o, p, y, x, b вместо а, е, о, р, у, х, ь. А пробелы и знаки препинания в utf-8 и так всего один байт занимают. И сразу получим уменьшение размера файла при том же тексте.

Потом вы передаёте этот файл другому человеку. Человек нажимает Crtl+F, пытается что-то найти, и через несколько попыток понимает, что проще будет найти вас и доходчиво объяснить, почему так делать не надо :D

Это извращение одним скриптом делается, но бить за это будут жестоко

лучше тогда хранить в txt.gz, правда, теряются некоторые преимущества.

но, на самом деле, такая экономия, скорее всего, мало кому нужна.

Во всех операционках от Microsoft ещё со времён MS-DOS поддерживалось прозрачное сжатие данных средствами самой файловой системы. Так что можно просто включить компрессию для папки с файлами, и сразу будет потребляться меньше места.

А вот линуксоидам не повезло - там всё настолько печально, что ни одна простая пользовательская ФС (типа ext3/ext4) прозрачную компрессию данных не поддерживает. Только разного рода монстроидальные серверные мамонты типа btrfs, которые пользователь поседеет настраивать.

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

НЛО прилетело и опубликовало эту надпись здесь

Markdown я полюбил бы только за то, что текст на нём вполне нормально читается даже без всяких просмотрищиков. Совешенно не понятно почему в современных web браузерах до сих пор не встроена поддержка md.

Кстати, Dropbox умеет показывать расшаренные по ссылке файлы, форматированные в Markdown.

Не знал. Закинул туда один свой файлик, в котором экспериментировал с markdown-разметкой и проверил, как он отображается.

Файл в Notepad++, в Confluence и в Dropbox отображается по-разному. С таблицами вообще беда

Насколько я помню, таблицы в спецификацию не входят.

И что вы хотели этим сказать? Этот самый расширенный синтаксис зависит от конкретной реализации md, будь то commonmark, gfm или что-то ещё.

Если нормально читается без просмотрщиков, то какая поддержка ожидается от браузера?

Часто вижу поддержку на серверах, автоматически транслирующих markdown в html, но это как раз для тех кто не хочет читать md. Да и учитывая огромный зоопарк диалектов markdown, делать это на сервере выглядит разумнее, чем на клиенте.

Markdown я полюбил бы только за то, что текст на нём вполне нормально
читается даже без всяких просмотрищиков. Совешенно не понятно почему в
современных web браузерах до сих пор не встроена поддержка md.

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

Markdown я часто использую во всяких своих локальных заметках для себя, но последнее время думаю а зачем, мог бы просто писать в html, благо браузер есть везде.

До сих пор не понимаю, чем в практическом смысле не угодил разработчикам markdown-а HTML. Потому что если ограничить HTML возможностями форматирования markdown, получится абсолютно то же самое. Особенно, если не требовать закрывающие теги.

Иными словами, что такого можно сделать в markdown, чего нельзя с такой же лёгкостью - в HTML.

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

Однако, это касается только языков, которые не используют латиницу.

Теги все равно длинные и нудные. Два энтера вместо <p></p> и два пробела и энтер вместо <br> — удобнее. Особенно это замечаешь, когда пишешь многострочную ячейку в таблице в md.
Это даже не вспоминая про списки. Вот чего мне не хватает для счастья — это авто нумерованных заголовков. С другой стороны — все равно никто не перенумерует ссылки на них, так как это в общем виде нерешаемая задача.

Мне в итоге пришла в голову идея делать так: https://top.ofthe.top/ru/buzz/tech/dealing-with-markdown-notes/

Если вкратце: просто эмбедим markdown разметку в html оболочку, а markdown разметка парсится на JS. В итоге у нас получается портабельный html, но при этом мы прямо внутри можем просто править markdown.

Сам очень люблю минимализм в файлах и текстовой формат это мой идеал.
Но вот разметку я всё таки предпочитаю использовать.
Для меня plain text это не только "чистый" txt, а намного больше.
К примеру, для текста использую кроме txt, md, html и tex, для домашней бухгалтерии ledger, для UML и всяких диаграмм plantUML, таблицы - csv.

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

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

А начинал я тоже когда-то с печатной машинки, правда на курсах "для секретарш" (да-да, когда-то это звучало именно так).
Не знаю или именно это привило мне приверженность к тексту или же моя любовь чтения и текста привела меня на курсы.

Сегодня благодаря юникоду многие проблемы с кодировками в прошлом.
А благодаря git и наличию двух трёх "хабов" за сохранность можно не беспокоится.

Сам очень люблю plain text форматы. Но в моем понимании md/adoc вполне plain text, тогда как html/latex -- уже нет, т.к. для минимально удобного чтения требуют преобразования (будь то рендеринг html с использованием, как минимум, layout engine, даже когда это кусок lynx или links; или преобразование в dvi/pdf).

Несмотря на все разглагольствования про отсутствие какой-либо разметки, пункты 4-8 всё же есть. Что мешает минималистично использовать относительно стандартные варианты markdown (commonmark/gfm) и asciidoc вместо изобретения очередного своего формата для списков, сносок и заголовков -- не ясно.

Сам очень люблю plain text форматы. Но в моем понимании md/adoc вполне plain text, тогда как html/latex -- уже нет, т.к. для минимально удобного чтения требуют преобразования (будь то рендеринг html с использованием, как минимум, layout engine, даже когда это кусок lynx или links; или преобразование в dvi/pdf).

Тут, наверно, у каждого своя граница удобности.
Я читаю и пишу "текст" html/latex на автомате.
В моих файлах часто попадаются формулы, как их выразить "словами" чтобы было всё понятно без LaTeX не знаю.
К примеру, \sum_{k=1}^{n} k = \frac{n(n+1)}{2} можно конечно описать как сумма всех чисел от одного до n равняется ... или сразу перегнать всеь текст в pdf.
Но увидев в тексте $\sum_{k=1}^{n} k = \frac{n(n+1)}{2}$ я сразу пойму что имеется ввиду, даже не видя рендер формулы.

Немного офтоп, но раньше, например, в Вавилоне именно так и записывали условия задач - словами:

«Четыре есть длина и пять есть диагональ. Какова ширина? Размер ее неведом. Четыре раза по четыре есть шестнадцать. Пять раз по пять есть двадцать пять. Вынимаем шестнадцать из двадцати пяти, остается девять. Сколько раз мне взять, чтобы получилось девять? Три раза по три есть девять. Три есть ширина»

Сам так делаю) Народ незнакомый с latex в телеграме парсит с некоторым трудом. Но формулы лишь малая часть, таблицы/схемы/beamer/кастомные макросы и вот это вот всё превращает его в несколько менее удобный формат для восприятия. Хотя своё с привычными макросами ещё ничего читать, если не спустя год-другой.

Если вы сгенерируете 10000 случайных символов и запишете в файл, то текстовый файл получится, а вот программа вряд ли. Вывод: программа не простой текстовый файл.

Программа - это простой текстовый файл, но простой текстовый файл это не всегда программа. Необходимо, но не достаточно.
Те от того что любой текстовый файл не программа, не значит, что программа не текстовый файл

Программа тоже не всегда простой текстовый файл, например Scratch.

Иногда программа - совсем даже не файл (перфокарты, перфоленты..)

Если вы сгенерируете 10000 случайных символов ...

Так и с таким текстом то же самое.

Символы есть а прочитать текст нельзя. Например, японец не прочитает ваш комметарий. Для него это не текст а набор символов.

Самое интересное, что документ Word, по сути своей, тоже "текстовый файл" XML упакованный в архив

это начиная с некоторой версии.

НЛО прилетело и опубликовало эту надпись здесь

более того, в основном английскими буквами (кроме 1С и Рапира).

Например программы на Excel

Эй, давайте причиним больше пользы!

Редактор под win - bred2. Прекрасен функционалом (особенно если размер шрифта увеличить), ужасен "последняя версия от 24 декабря 2000". Есть на что поменять? Far тоже использую.

И хочу что-нибудь под android (сейчас - быстрый блокнот (fastnotepad) но у него немного другой функционал, не хватает... синхронизации что ли. С dropboxом каким нибудь. Последний кстати до какой-то поры умел работать с txt, а потом разучился в кодировках :(

AkelPad (можно с минимальным набором плагинов). Говорю как бывший поклонник Bred`a.
*upd:
- для любителей минимализма - TednPad;
- для продвинутых - Notepad2;
- для окончательно продвинутых - Notepad++ и Programmer's Notepad.
А вообще-то Bred3 есть тоже.

Ну акелпад с 2016 года не обновляется. =(
Правда я всё равно им пользуюсь уже порядка 15-20 лет, наверное. Ещё с XP начал (на установочном диске был набор софта, в том числе бред с акелпадом, помнится).

НЛО прилетело и опубликовало эту надпись здесь
А надо?
Даже не скажу. Большая часть функционала меня вполне устраивает.
Разве что для плагина Coder пришлось самому делать конфиг подсветки синтаксиса и автодополнения (нет там ничего для языка SourcePawn).

Разве что хотелось бы чуть большую скорость открытия файлов большого размера (десятки МБ и больше).

А еще есть Notepad3 - форк Notepad2

Меняйте хлеб на чай. Редактор Tea - последняя версия в этом году была.

Сейчас слезы польются. Bred разрабатывала та же компания, что и AstonShell.

Для редактирования текста использую Markor. Для синхронизации Dropsync: Autosync for Dropbox. Работает на телефоне и планшете. Ну ещё и на компе, но там уже idea и обычный dropbox.

Пробовал текстовые редакторы с поддержкой синхронизации, но не понравилось что они не такие функциональные как Markor и они только текст синхронизируют с локальной копией, а удобнее всю папку синхронизовать (например когда в asciidoc/md картинку вставляешь то удобнее если она рядом в папке лежит).

И хочу что-нибудь под android

https://play.google.com/store/apps/details?id=com.rhmsoft.edit
Даже регкспы поддерживает, но в формате Оракл — это надо учитывать


А так — открыть fb2, удалить из него все картинки, переименовать героев — все в два клика

Мне думается, что немного путается текстовые файлы, текстовый формат, plain text и пр. Особенное если речь начинается с печатных машинок.

Может быть стоит говорить о текстовых файлах, как о файлах без непечатных символов, т.е. без бинарных (двоичных) данных?

И как правильно выше заметили, у текстовых файлов может быть и Структурированность и Форматирования и Не Линейность.

"Может быть стоит говорить о текстовых файлах, как о файлах без непечатных символов, т.е. без бинарных (двоичных) данных?"

"Перевод строки" и "Возврат каретки" вполне себе непечатные символы. Не единственные.

Это не непечатные, а управляющие символы (https://ru.wikipedia.org/wiki/Управляющие_символы).

Хоть они так же как и непечатные символы не имеют графического представления во время печати, но используются в текстовых форматах для выполнение определенных действий.

Так они под ваше определение " бинарных (двоичных) данных " вполне попадают. Как-то надо определится..

Интересно, а кому-нибудь пришлось попользоваться такими программами как: ЛЕКСИКОН, Chiriter и Emacs?

Мне думается, что немного путается текстовые файлы, текстовый формат, plain text и пр. 

В этом вся соль! Это смешение происходит на уровне операционной системы. Вот и имеем, что имеем.

Сперва был Чирайтер. Но очень недолго, так как полявился лексикон. Все договора у меня были в лексиконе. Да, я старый :)))))) Еще бывло СловоиДело под дос. А еще был ворд под дос, вроде 4 или 5 версия. Но лексикон всех побеждал, так как в те времена была проблема кирилицы.

У ChiWriter была одна серьезная проблема - текст набранный на одной машине, мог некорректно отображаться на другой. Лексикон был хорош. Правда потом был геморрой с переносом текстов в Ворд, но для этого был конвертер. Слово и Дело вроде а́ был лучше лексикона, но я в то время уже сидел на Винде.

Интересно, а кому-нибудь пришлось попользоваться такими программами как: ЛЕКСИКОН, Chiriter и Emacs?

Один из лучших текстовиков для DOS -- "Слово и дело", ммм... какие там были таблицы, списки, шрифты, и WYSIWYG для матричных графических принтеров.

Особенно весело разбирать форматирование лексикона в современном мире. Хорошая разметка, да

То ли в Лексиконе, то ли в W&D таблички удобно было рисовать.

Таблицы я превращаю в списки. Обычно это очень легко сделать.

И как это сделать визуально читаемым для таблицы на 3-5 столбцов и столько же строк?

Таблицы переводятся в текст длиной 9-25 строк соответственно. Этот совет подходит только для табличек совсем небольшого размера. Что будет с таблицей 20х10 даже сложно представить. Чисто теоретически, можно было бы сделать реализацию markdown с поддержкой csv. Но тут есть другая загвоздка, см. мем "есть 14 конкурирующих стандартов".

в AsciiDoc таблицы легче делать, чем в Markdown - тут каждая колонка это отдельная строка.

Это чисто стилистическое. Если хочется -- можно все колонки в одну строку или в смеси.

The suggestion to start each cell on its own line and to separate rows by empty lines is merely a stylisic choice. You can enter more than one cell or all of the cells in a row on the same line since the processor creates a new cell each time it encounters a vertical bar (|)

Старого пса новым фокусам не обучишь, но вдруг.

Простые текстовые файлы безо всякого форматирования много лет остаются на вершине моего личного хит-парада способов хранения информации

Я никогда не использую табуляцию.

И много теряете.
Если все-таки использовать табы в начале строк (и работать в чем-то вроде Sublime, поставив в настройках "indent_subsequent_lines": true, а сам таб отображая длинным, под дюжину пустых символов), то это позволяет гораздо удобнее не только читать, но и ориентироваться и РАБОТАТЬ внутри текста, если он большой и сложноструктурированный. Помимо того, что это просто наглядно (в том числе и по миникарте), появляется возможность свертки/раскрытия блоков, оставляя только их названия. Очень помогает, когда файл переваливает за размер миникарты, а хочется посмотреть всю структуру сразу.
При этом главное достоинство текстового файла (есть только те символы, которые вы вводили и видите) сохраняется.

А ты вступил в кружок текстовых браузеров ??)

Любите ли вы рысей так, как люблю их я?

Чувак, ты постиг дзен.

Заслуженный + и подпишусь под каждым словом
AlkePad открыт всегда на рабочем столе

А смысл его держать открытым постоянно?
Он же и так достаточно быстро открывается. И запоминает позицию на которой был открыт (правда не уверен, что запоминание не ограничено последними открытыми n файлами, не проверял таки последние n файлов, в настройках задаётся количество).
Ещё бы можно задать кодировку по расширению файлов (автоматическая иногда не справляется и открывает некоторые файлы в неправильной кодировке, поэтому поставил принудительно UTF-8).

Ну а как же, удобнее вести длинный лог, а не мельчить множеством файлов. Мой (4.9.8) вроде не автосохраняется и открывается с чистым файлом.

Настройки ==> Параметры… ==> Реестр ==> блок Последние файлы ==> Запоминать позицию каретки


Сделал, спасибо за наводку. Кстати, что вы думаете насчет плагинов к нему? Есть опыт использования?

МИспользую некоторые из дефолтных:Coder, LineBoard, QSearch, ToolBar и немного XBrackets.


Кстати, только что чего-то решил таки убать лишние для меня кнопки с панели плагина ToolBar, хотя давно дефолтным конфигом пользовался с кучей кнопок которые ни разу не были нужны. =)

Это всё замечательно, но если вы сделаете ваши текстовые файлы одновременно и маркдаун-текстом, буит ваще огонь.

НЛО прилетело и опубликовало эту надпись здесь
Например, однажды я усердно перепечатал довольно объёмную книжку с тестом на IQ. Эта книга была чужая, её нужно было вернуть владельцу через несколько дней. Мне же она настолько понравилась, что захотелось сохранить себе копию. Сканеры и ксероксы, если тогда и существовали, были недоступны.

Я очень хорошо помню этот период (1976-1977 г.г.), когда машинистки были очень уважаемыми людьми. А какой восторг испытал и я и окружающие меня сослуживцы когда мне удалось автоматизировать процесс выдачи отчетов на ЭВМ М-220 с помощью этих текстовых файлов, хранимых на магнитных лентах:


Всё это мне не помешало завершить к февралю 1978 года работу над своим детищем – генератором отчетов РПГ М-220. Женщины отдела помогли мне оформить и выпустить в четырёх экземплярах документацию. Особую гордость у меня вызывала коленкоровая обложка у неё. В это время у нас работала очередная комиссия. Требовалось много справок и отчетов годовых/полугодовых, сколько и каких спутников летало тогда и тогда, каких и сколько телеграмм перехвачено и т.д. Женщины в отделе напряглись. И тут на первый план вышел я со своим РПГ:
image

Чем вам FB2 не угодил? Я в курсе,что это типа электронная книга. Но. Переименуйте его в txt и читайте где хотите.

И как по мне, автор лукавит. Призывает к тексту без форматирования. И выкатывает 10 правил форматирования.

Автор! Текст без форматирования - это слова разделённые пробелами и знаками препинания. Читать такое - тихий ужас. Даже перевод строки - это уже форматирование.

+ за «И выкатывает 10 правил форматирования.» но не за FB2 который надо читать в виде txt, так и HTML можно читать, но смысл в том, чтобы удобней набирать почти так же как txt. А когда кучу разных правил, да усложненных, то их никто и не хочет выполнять. А читать можно во многих форматах, но удобней в специальных редакторах.

Переименуйте его в txt и читайте где хотите.

Там внутри XML. XML - это не формат для людей.

fb2 — удовищное грибовское поделие, несовместимое ни с чем, не имеющее четкой спецификации, ни одной программой нормально туда-обратно не конвертируемое, потому все автоматические конверторы — конвертят его исключительно криво. ЧСХ — с нормальными форматами они справляются без проблем


А сам фб2 нормально редактируется только дремучей программой, которая вот-вот вообще перестанет запускаться на современной винде


Здорово грибузер поднасрал этим форматов отечественным библиотекам...

Здорово грибузер поднасрал

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

Нормальная вещь за свои деньги получилась. Альтернативы ничем не лучше.

Кривая софтина, к сожалению. И пользуются ей далеко не все, очень далеко. По сути, только несколько русских библиотек

Кривая софтина

Что в нашем мире прямого? ;)

По сути, только несколько русских библиотек

Для самиздата и пиратских переводов нормально зашла, другого от нее и не требовалось. Деньги в этой области ходят, но в основном мимо. Хотя, там где деньги ходят (epub-pdf-etc) - альтернативы ещё хуже.

Если бы только самиздат


Флибуста и Либрусек — тотально. Там это как основной формат хранения. Уж лучше быть простой html...

Флибуста и Либрусек

Пираты и корсары ;)

" Уж лучше быть простой html... "

А скажите пожалуйста, бывает файл html на несколько сотен страниц, с десятками картинок в виде ЕДИНОГО файла. Я в самом деле не знаю. Я не спец, а просто так мне такие файлы не попадались.

И в чём читать такие файлы? Браузер не предлагать! Там десятой доли возможностей читалок нет.

бывает файл html на несколько сотен страниц, с десятками картинок

epub ;) Это 100500 xhtml файлов, упакованные в zip. Открывать читалкой ;)

PDF как электронная книга?

Очень часто бывает

раньше был формат .mht , я в него странички с картинками сохранял

Ага, архив с html внутри. Не помню zip или ole, но гадость ещё та была

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

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

Опера вроде тоже так умеет: Ctrl+S (или клик правой кнопкой мыши и выбрать «Сохранить как...») ==> в появившемся окне выбрать тип файла "Страница (одним файлом) (*.mhtml)".
Правда киррилицу внутри файла сохраняет вот в таком виде:
<div class=3D"comment__message  comment__message_v2  "><p>=D0=9A=D0=
=BE=D0=BD=D0=B5=D1=87=D0=BD=D0=BE =D0=B1=D1=8B=D0=B2=D0=B0=D0=B5=D1=82. =D0=
=9D=D0=B0=D0=BF=D1=80=D0=B8=D0=BC=D0=B5=D1=80, =D0=B1=D1=80=D0=B0=D1=83=D0=
=B7=D0=B5=D1=80=D0=BD=D0=BE=D0=B5 =D1=80=D0=B0=D1=81=D1=88=D0=B8=D1=80=D0=
=B5=D0=BD=D0=B8=D0=B5 SingleFile =D0=BF=D0=BE=D0=B7=D0=B2=D0=BE=D0=BB=D1=8F=
=D0=B5=D1=82 =D0=BB=D1=8E=D0=B1=D1=83=D1=8E =D0=98=D0=BD=D1=82=D0=B5=D1=80=
=D0=BD=D0=B5=D1=82-=D1=81=D1=82=D1=80=D0=B0=D0=BD=D0=B8=D1=87=D0=BA=D1=83 =
=D1=81=D0=BE=D1=85=D1=80=D0=B0=D0=BD=D0=B8=D1=82=D1=8C =D0=B2 =D0=B2=D0=B8=
=D0=B4=D0=B5 =D1=82=D0=B0=D0=BA=D0=BE=D0=B3=D0=BE =D0=B5=D0=B4=D0=B8=D0=BD=
=D1=81=D1=82=D0=B2=D0=B5=D0=BD=D0=BD=D0=BE=D0=B3=D0=BE =D1=84=D0=B0=D0=B9=
=D0=BB=D0=B0. =D0=92 =D1=84=D0=B0=D0=B9=D0=BB =D0=B7=D0=B0=D0=B2=D0=BE=D1=
=80=D0=B0=D1=87=D0=B8=D0=B2=D0=B0=D1=8E=D1=82=D1=81=D1=8F =D0=B8 =D0=BA=D0=
=B0=D1=80=D1=82=D0=B8=D0=BD=D0=BA=D0=B8, =D0=B8 =D1=81=D1=82=D0=B8=D0=BB=D0=
=B8. =D0=A1=D0=B0=D0=BC=D0=BE =D1=80=D0=B0=D1=81=D1=88=D0=B8=D1=80=D0=B5=D0=
=BD=D0=B8=D0=B5 =D0=BD=D1=83=D0=B6=D0=BD=D0=BE =D1=82=D0=BE=D0=BB=D1=8C=D0=
=BA=D0=BE =D0=B4=D0=BB=D1=8F =D1=81=D0=BE=D1=85=D1=80=D0=B0=D0=BD=D0=B5=D0=
=BD=D0=B8=D1=8F - =D0=BF=D1=80=D0=BE=D1=81=D0=BC=D0=B0=D1=82=D1=80=D0=B8=D0=
=B2=D0=B0=D1=82=D1=8C =D1=8D=D1=82=D0=BE=D1=82 =D0=B5=D0=B4=D0=B8=D0=BD=D1=
=8B=D0=B9 =D1=84=D0=B0=D0=B9=D0=BB =D0=BF=D0=BE=D1=82=D0=BE=D0=BC =D0=BC=D0=
=BE=D0=B6=D0=BD=D0=BE =D0=B2 =D0=BB=D1=8E=D0=B1=D0=BE=D0=BC =D0=B1=D1=80=D0=
=B0=D1=83=D0=B7=D0=B5=D1=80=D0=B5.</p><p>=D0=9E=D1=87=D0=B5=D0=BD=D1=8C =D1=
=83=D0=B4=D0=BE=D0=B1=D0=BD=D0=BE, =D0=B5=D1=81=D0=BB=D0=B8 =D0=BD=D0=B0=D0=
=B4=D0=BE =D1=81=D0=BE=D1=85=D1=80=D0=B0=D0=BD=D1=8F=D1=82=D1=8C =D0=B8=D0=
=BD=D1=82=D0=B5=D1=80=D0=B5=D1=81=D0=BD=D1=8B=D0=B5 =D0=B3=D0=B0=D0=B9=D0=
=B4=D1=8B =D0=B8=D0=BB=D0=B8 =D1=81=D1=82=D0=B0=D1=82=D1=8C=D0=B8, =D0=B0 =
=D1=82=D0=BE =D0=BA=D0=BE=D0=BB=D0=BB=D0=B5=D0=BA=D1=86=D0=B8=D0=BE=D0=BD=
=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D1=82=D1=8C =D1=81=D1=81=D1=8B=D0=BB=D0=BA=
=D0=B8 =D0=BD=D0=B0 =D0=BC=D0=B0=D1=82=D0=B5=D1=80=D0=B8=D0=B0=D0=BB=D1=8B =
=D0=B2 =D0=98=D0=BD=D1=82=D0=B5=D1=80=D0=BD=D0=B5=D1=82=D0=B5 =D0=B1=D0=B5=
=D1=81=D0=BF=D0=BE=D0=BB=D0=B5=D0=B7=D0=BD=D0=BE - =D0=BB=D0=B5=D1=82 =D1=
=87=D0=B5=D1=80=D0=B5=D0=B7 =D0=BF=D1=8F=D1=82=D1=8C =D0=BF=D0=BE=D0=BB=D0=
=BE=D0=B2=D0=B8=D0=BD=D0=B0 =D1=81=D0=B4=D0=BE=D1=85=D0=BD=D0=B5=D1=82.</p>=
</div>

Без проблем можно завернуть картинки в data:uri и встроить прямо в код.

chm, но винда его похоронила. (хелп в общем, мог перепутать за давностью лет буковки, но вроде так)

CHM был всё равно слишком ориентирован на конкретное применение (файлы справки).

PDF как электронная книга? Упаси Господи! Уж лучше plain text.

Внутри plain text очень трудно делать сноски, поиск, справочный аппарат.


Пример. Автор написал текст и сделал сноски, которые надо читать одновременно с текстом. Затем автор сделал ещё другие сноски, в которых указаны ссылки на литературу. Потом редактор сделал ещё сноски, в которых даны примечания редактора.


Пример. В тексте на шести страницах упоминается Иван Иванович Петров, однако автор нигде не пишет его фамилию. В PDF-книге эта фамилия будет записана в именном указателе.


Пример. В тексте нигде не выделена навигация по хронологии. В PDF-книге на полях можно указывать годы, о которых идёт рассказ, и тем самым ускорять ориентировку в тексте.


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

В тексте на шести страницах упоминается Иван Иванович Петров, однако автор нигде не пишет его фамилию.

Напоминает небезызвестный анекдот про вопрос ЕГЭ — "как звали Александра Сергеевича Пушкина?"

Ну да, фамилия Ивана Ивановича указана только в именном указателе. Что же вас удивляет? Странно, что удалось выяснить фамилию? Текстологи не зря едят свой хлеб и многое умеют.

Все эти преимущества разбиваются об два простых факта

  1. PDF невозможно штатно масштабировать (это фича)

  2. Большая часть PDF файлов не адаптирована под размер экрана читалки

В итоге, каким бы классно индексированным PDF ни был, он будет либо некомфортно мелким (потому что вы пытаетесь впихнуть A4 на 6 дюймов), либо его придется постоянно скроллить туда-сюда, что на E-ink с его откликом нутакое себе

Тут все вопросы к издательству.Почему бы не издать ту же книгу в формате А5?

Или просто издать её в формате, который умеет масштабироваться под любой экран и предпочтения ¯\_(ツ)_/¯

издать её в формате, который умеет масштабироваться под любой экран и предпочтения

Например? ;) С графиками, иллюстрациями и таблицами, пожалуйста.

Что угодно будет масштабироваться лучше PDF. Я же не предлагаю "идеально" — хотя бы как то, в отличие от

Действительно, pdf верстается под определенный размер экрана ;) Он совсем не для масштабирования придуман.

Но как только на странице появится что-то более сложное чем просто текст - без pdf никак. Во первых стандарт, во вторых - переносимый.

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

Вот что ж за говноструктура должна быть там под капотом, чтобы даже на двенадцатиядернике с 64 Гб памяти странички какого-нибудь DnD Monsters Book Manual или Citadel Painting Guide рендерились по 5 секунд?

Проще отрендерить всё напрямую в пачку PNG/JPG и получить ещё большую переносимость, только без идиотских тормозов и выжирания батареи за 15 мин.

PDF создавался очень давно, как формат, который будет отображаться везде одинаково, а также печататься везде одинаково. Вот reader-ы для него - очень разные. У меня он тормозит в Acrobat Reader, но шустро открывается в browser-е, например.

Вы же (пусть и иронично) предлагаете pre-render под единственное разрешение экрана, и это - ерунда. Даже древние растровые альтернативы (MrSID, DjVu, ECW, JP2k), по крайней мере, учитывали это и предлагали хранить структуры, удобные для рендеринга разных разрешений.

Вот что ж за говноструктура должна быть там под капотом

Программа для движка pdf ;) Внутре там - инструкции, как отбражать документ. Текст там тоже есть, но мало.

Ну вот взять например проигрыватель видео. Он сперва должен распаковать изображение, упакованное с помощью весьма хитрой математики. Причём изображение в высоком разрешении, бывает и выше 4к. Далее на это изображение накладываются субтитры, то есть рендерится тот же самый текст. Текст этот с разметкой - там разные шрифты, цвета, позиционирование, может присутствовать прозрачность.

И при этом пригрыватель ухитряется даже на весьма тухлом оборудовании рендерить не менее 30 таких кадров в секунду. И ещё на звук время остаётся.

Так почему же pdf настолько убог, что его вообще невозможно рендерить с такой же скоростью, как mp4/mkv?

В слове pdf буква О отвечает за оптимизацию ;)

Далее на это изображение накладываются субтитры, то есть рендерится тот же самый текст. Текст этот с разметкой — там разные шрифты, цвета, позиционирование, может присутствовать прозрачность.
Субтитры — это отдельный текстовый файл, где прописаны все необходимые параметры текста (собственно текст, тайминги, шрифт, размеры, положение, оформление). Сам файл/файлы субтитров обычно встраиваются в контейнер (mkv, mp4, etc.), но могут быть и отдельным файлом (вроде не все проигрыватели поддерживают внешние субтитры).
Шрифты же нужно в систему отдельно устанавливать, насколько мне известно.
  1. PDF векторный.


  2. Чертежи и диаграммы не адаптированы под размер экрана читалки.


  1. Речь шла о масштабировании вида "сделать текст покрупнее"

  2. В изначальном комментарии говорилось про книги

Upd: вставить картинку с чертежом можно и в масштабируемый формат

  1. Конечно, книги. В них и карты бывают, и формулы, и ссылки, и маргиналии, и примечания. Книга — это вовсе не поток текста.

И даже фраза "как видно в иллюстрации на следующей странице" останется живой если перерендерить с другим размером шрифта?
А в больших книжках такое — сплошь и рядом.

Теоретически - да, если разбиение на страницы сделано по каким-то маркерам, которые привязаны к концу абзацев.

Как раз масштабировать PDF можно сколько угодно (уменьшать и увеличивать всю страницу целиком). Вы же говорите не о масштабировании, а, фактически, о переформатировании - изменении размера шрифта.

Масштабирование книги - это изменения размеров шрифта без нарушения структуры текста. Проще говоря, увеличив масштаб, вы будете видеть на экране большее или меньшее количество последовательных слов ОДНОГО предложения.

Увеличив масштаб в в PDF вы будете видеть на экране начала, середины и окончания РАЗНЫХ предложений. Если ширина текста больше разрешения экрана, то вам придётся постоянно двигаться от начала к концу предложения и ОБРАТНО. Чтобы начать читать следующее предложение.

Именно по этому для меня простой текст лучше PDF. Все редакторы умеют подгонять его ширину под ширину экрана.

И да, в PDF это не лечится. Неизменность вида - то, для чего он разрабатывался.

Книга — это не только текст, и далеко не текст.


Как правильно изменить масштаб векторной карты? Как редакторы подгоняют ширину карты под ширину экрана?

Наверное от карты зависит. И от редактора.

Книга- это В ОСНОВНОМ текст. А с остальным можно перемучится.

Я это не от фонаря говорю. Чтение PDF мануалов на планшете 800х600 - вырвиглаз удовольствие.

простой текст лучше PDF

не всегда

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

… и при этом название колонки вверху и значение далеко внизу, когда строк много.

Плохую картинку привели

Норамальная картинка. С интересом понаблюдаю, как её заменит plain text ;)

Надо было таблицу.

Таблица еще хуже. Хоть внутри нее plain text, но любая адаптивная верстка превратит ее в нечитаемое непоймичто.

PDF невозможно штатно масштабировать (это фича

Не совсем так. Для "обычного" пдф - это правда. Но лет 15 назад появлялась фича с названием что-то вроде "режим чтения". Это было именно такое масштабирование, как вы хотите. Но для его работы пдф должен был быть создан каким-то специальным образом, а не просто принтером в пдф

Для облегчения работы с текстами я использую специальную раскладку клавиатуры, в которой есть нужные символы: кавычки «», разные виды тире и другие часто используемые знаки.

Какую именно?

Я раньше пользовался программой Typeiteasy, но на win 10 она сильно глючила (а на win 11 уже и не пробовал). Какие-то другие варианты пробовал - не понравились.

Особенно не хватает кнопки ударения. Также нужны разные тире, градусы, квадрат и куб, 1/2, 1/3, неразрывный пробел... Старомодный параграф и новомодный рубль тоже не помешали бы...

Спасибо, попробую и Keybord_Assistant. У вас там описание Гугл делал?)

Программа помогает в переключении раскладок клавиатуры, добавляет бирманскую раскладку

Типа да, где-то перевод с одного языка на другой гуглом, так что как есть :) Оттуда можно вырвать нужный кусок кода для задания символов. Бирманская раскладка проще реализует, правда проблема есть если горячие клавиши уже заняты (Ctrl+Alt+Буква) или правый альт используется в других языках (в анг. и русском все свободно, так что проблем нет).

Мне кажется граница определения plain text у каждого может быть своя. Для кого-то это только чистый текст без всяких, пусть даже и упрощённых, разметок. Другой спокойно воспринимает html или LaTeX ещё как plain text.

Моя - достаточно широкая, хоть и не однозначная даже для меня. С одной стороны я признаю, что xml это всё тот же текстовой файл, но для меня он как-то уже не по дзену plain text из-за своего "засорения" для глаз и бо́льшую ориентацию на программу, а не на программиста.

Вообще структурированный текст может быть полностью понятным и при этом иметь основную функцию для программы. Речь не о программном коде, для понимания которого нужно учится, а, к примеру, о данных типа ledger.

Можно написать 16 апреля 2023 купил на базаре яблок наличкой на 10000, а можно сразу так:

2023/04/16  яблоки с базара
    Расходы:Покупки:Продукты             100000
    Активы:Наличка

Как в первом так и во втором случае сразу видно про что идёт речь, но во втором случае за счёт структуры, имхо, увидеть и понять информацию намного легче. Это всё продолжает быть текстом, который можно написать и прочитать в редакторе и спросить себя зачем купил яблок на всю многоэтажку, а можно прогнать hledger-ом и увидеть больше интересной информации из простого текстового файла.

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

Идеальная статья для Хабра. Содержательного наполнения — ноль целых ноль десятых, зато десятки комментов «да-да, я такой же, как автор!» и «а вот смотрите как автор лукавит!».

Ссылки и оглавление — вот что режет plain txt на корню, безжалостно и насмерть


Мне кажется, автор путает простой формат и простое оформление.
Вообще, правила хорошего шрифтового дизайна для текста большого обьема — предполагают почти все то, о чем писал топикстартер: использование минимума гарнитур, однородное и простое оформление абзацев, умеренное использование акцедентного форматирования и тд тп


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


Не вижу ни одной причины насильно кастрировать современные возможности разметки, получая единственный плюс — аппаратную и софтовую независимость. Сейчас любая система, по дефолту умеет показывать тот же самый html, в каких условиях надо оказаться, чтобы не открыть этот формат?


При том, автор пользуется юникодом — а это довольно современная надстройка и с ней проблем может быть куда больше, чем с простейшим ascii в 256 символов и тегами разметки. При этом, первый вариант будет "пустой", а второй — удобно структурированный и отформатированный

Одна строка — один абзац. Раньше любили использовать «красивое» форматирование с выравниванием текста в блоки заданной ширины. Так, например, оформлены тексты на lib.ru. Я никогда так не делаю. Пусть переносом слов внутри абзаца занимается текстовый редактор или программа просмотра.

Как у вас переносятся слова одной строки в FAR? Какие плагины используете для этого?

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

Как у вас переносятся слова одной строки в FAR? Какие плагины используете для этого?

Не совсем понял, что конкретно Вы спрашиваете, но https://plugring.farmanager.com/plugin.php?pid=292

Так Format Block ломает концепцию одна строка — один абзац, разделяя строку на несколько строк по ширине экрана. Если писать текст в один абзац без переносов строк, то приходится пользоваться горизонтальным скроллом, что не очень удобно.

Если писать текст в один абзац без переносов строк, то приходится пользоваться горизонтальным скроллом,

...или нажать Shift-F2 (в стандартном фаровском вьювере)

Жаль, что в стандартном фаровском редакторе нет такой функции.

Доброго дня! Немного странный вопрос, но, может, кто подскажет... Год назад перешел с Bred2/3 на Notepad++. Требуется создавать в win11 такие файлы на кириллице, которые потом будут в максимальном числе случаев автоматически (т. е. при дефолтных настройках) корректно открываться в большинстве программ, как на компе, так и на телефонах (в основном на Андроид). Путем тестирования штук 15 редакторов был выбран режим создания текстовых документов в Notepad++ в "UTF-8 с BOM". Но иногда даже такие документы открываются в виде кракозябр, причем, на телефонных просмотрщиках не всегда удается перевести их в нормальный текст. Может, подскажите какую-то другую более универсальную кодировку или другой редактор?

Увы, но если ваши телефоны глючат, то виноват не редактор(ы), так как https://ru.wikipedia.org/wiki/Маркер_последовательности_байтов смотрите тут и можно увидеть, что все четно. Если кракозябры, то может используете иероглифы, тогда UTF-16 (LE) использовать можно....может тогда их китайские телефоны поймут русский.

Не люблю усложнять простое, но все же.

Мы хотим видеть текст в красивом и отформатированном виде (так воспринимать удобнее), но в таком случае текст состоит из двух логических частей: непосредственно сам текст и его форматирование.

Может тогда отделить мух от котлет и хранить текст в своем отдельном файле .txt и форматирование в своем файле? Потом оба файла сжать архиватором и готово.

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

Минусы:
- Повреждение архива чревато потерей данных (но можно обойти если использовать сжатие с recovery как в Winrar)
- Нужен архиватор (но он по умолчанию есть во всех ОС)

А как? или мегаредактор которым только и можно это править, или я не понимаю, как вы будете использовать форматирование типа


Мопед — транспортное средство с [ДВС][ДВС] объемом до 50 см^3 или электродвигателем мощностью менее 250 ВТ


А жирный, курсив, верхний индекс и ссылку во второй файл. После этого редактируете заголовок этого файла, сносите пару абзацев вниз и на что будет ссылаться форматирование? Номер абзаца, количество символов и тд и тп безнадежно уехали. А если разметить весь файл с текстом якорями — то он станет сильно не плайн.

Поддерживаю. Именно минимализм позволяет уловить суть и не сходить с ума настраивая детали.

Лично мне нравится подход, который выбран в Obsidian (приложение для ведения заметок). В редакторе используется синтаксис Markdown, а если и этого мало можно вставить кусок на HTML.

Таким образом стараюсь писать обычным текстом, если все же нужно что-то выделить, выделяю разметкой md. Ну и совсем на крайний случай html. Минималистично, версионируемо. Все заметки хранятся в иерархии папок. Сами заметки тоже хранятся в обычных файлах. Вообщем красота. Есть конечно и минусы, но это уже другая история.

>Для того, чтобы написать любой текст, я всегда сначала открываю простой текстовый редактор.

с авто проверкой орфографии и авто дополнениями ?

"Любимое развлечение в детстве", а не знаете, что машинка-то ПИШУЩАЯ, а не печатная. Эх-ма!

Но машинка же не пишет, а именно ПЕЧАТАЕТ ;)

И был "Лексикон". И были мы счастливы!!

А также культовый редактор "Слово и Дело". На самом деле это всё было нереально удобно - при редактировании ссылки по тексту, редактирование сразу нескольких мест в файле, "резиновые" таблицы через символы псевдографики, которые стрелочками могли менять ширину колонок и умели заворачивать текст в ячейках. А на выходе - обычный текстовый файл, который читается и печатается всюду.

Однажды из-за сбоя я потерял ценные файлы, которые не попадали в бэкап. Один из них был текстовым и никакие программы восстановления не могли его найти. В итоге решил сканировать весь SSD (250 гигабайт) через хекс-редактор в поисках слов из этого текстфайла. Вспоминал, какие были наиболее редкие и на каждый полный поиск уходило 20 минут. В итоге таки нашёл — визуально в хекс-редакторе было видно, как часть файла была перезаписана чем-то другим. Эту потерянную часть я уже восстановил по памяти.
Не знаю что бы делал, если бы текст был в другом, сложном формате.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории