Такой кейс уже не отрабатывает, поскольку стек кавычек сбрасывается вместе со всем остальным контекстом. На выходе даёт
'<p>«начало „текста </p><p>конец» текста»</p>'
Должен ли он отрабатывать — вопрос сложный. С одной стороны вроде бы логично, но с другой, (а) непонятно, допустимы ли в нормах типографики вложенные цитаты на несколько абзацев, и (б) не хотелось бы, чтобы лишняя кавычка в длинном тексте сдвигала расстановку кавычек в непредсказуемом месте, а то и во всём остальном тексте. Пожалуй, минусы перевешивают, и оставлю-ка как есть, на совести редакторов :)
Я не прав, если вы успели прочитать мой коммент, то забудьте :). Оно действительно заменяется, но не так, как я описал, а просто потому что кавычка привязана к слову слева или справа, блоки тут ни при чем.
Интересный кейс, не приходило в голову. несмотря на то, что используются блочные теги, стек кавычек ведётся глобальный для всего текста, поэтому кавычки заменяются. При переходе от одного блока к другому обнуляется итератор предыдущих и следующих элементов, может что-то еще.
3. Весь текст разбивается на токены в соотвествии с содержащейся в классе токена регуляркой. При этом каждый токен сохраняет ссылку на место в дереве lxml ElementTree, из которого он взят ([1], [2]).
4. Затем мы проходимся по списку всех токенов и вызываем для каждого функцию преобразования. На входе — итераторы следующих и предыдущих токенов. Итератор возвращает токены-фрагменты текста вне зависимости от тегов, так что при применении правил теги игнорируются.
5. Каждый токен содержит набор правил в виде произвольного кода на питоне, он может смотреть на предыдущих и следующих соседей, может менять, добавлять, удалять соседние токены или самого себя.
А, вижу что-то похожее, но кажется, всего один случай.
Например, мой вот этот кейс у вас не проходит, судя по всему (если я всё правильно сделал в демо) — вместо одного неразрывного получается один обычный и один неразрывный.
Еще бросается в глаза смешение работы в текстовом режиме и html. Например, сокращать пробелы до одного и переводы строк до двух максимум имеет смысл для plain text, в то же время, там же есть и теги. Конечно, вряд ли это может создать проблемы, и в некоторых случаях даже подходит, например, для редактора комментов хабра :) Но какой-то червячок внутри меня мне упорно твердит, что разделение методов работы с plain text и html в вебе — это хорошая практика.
Ну и здесь у меня разные издевательства над HTML посреди текста. Вполне вероятные кейсы для данных, поступающих из визивига. Это главная причина, почему я написал свой типограф, потому что сделать такое на регулярках довольно непросто. Неясно, поддерживается ли это у вас, по крайней мере, тестов не вижу…
еще у меня есть ощущение, что английские кавычки расставляются у вас все же неправильно.
Это мы какую-то книжку нашли, в которой были описаны правила. В ридми есть ссылка на нее, правда, на другой фрагмент. Найти сейчас ее наверно будет непросто. Я завтра перепроверю по вашей ссылке.
html тайпус никак не модифицирует, у вас заметил теги в нижнем регистре
Это lxml виноват :)
Пожалуй, еще добавлю, что тайпус понимает миксованный EnRu текст.
chakert опирается на атрибут lang, если он есть. Тут тоже вопрос кейсов, у нас смешанных текстов нет.
PS. В продакшне чуть больше года на нескольких проектах, через типограф в принудительном режиме пропущено пару сотен тысяч текстов новостного формата в виде фильтрованного HTML, и каждый день пропускается порядка нескольких десятков. Пока нареканий со стороны редакторов не было.
В имеющихся меня не устраивало, что, во-первых правила замены оформлены в виде регулярок, что лично для меня категорически неудобно (у вас, судя по всему, тоже :( ). Особенно, разбираться в чужих регулярках.
Во-вторых, это танцы с бубном вокруг HTML. Он либо эскейпится, а затем раскрывается, либо удаляется, а потом возвращается на место. В первом случае мы получаем, что даже пустой тег, вставленный в неудачном месте, может повлиять на результат, а второй вариант мне не нравится непредсказуемостью, не вызывает доверия.
У меня исходный текст разбивается на токены с использованием регулярок, а затем перебираются все токены и у каждого вызывается метод замены: получает на вход итератор предыдущих и следующих токенов и умеет заменять себя или соседей на любой другой токен.
При этом токены остаются связанными со своими тегами, и при сборке обратно в текст всё само встает на свои места.
Русский + английский. Py2.7, py3.4 (нужно, кстати, освежить...)
И все-таки, условие задачи непольное. Раз используется какая-то аксиома, тем более, что эта аксиома «принимается не всеми математиками безоговорочно: некоторые относятся к ней с недоверием», то в условии нужно указать, что эту аксиому можно использовать.
Потому как решение, базирующееся на другом наборе аксиом может сильно отличаться или не существовать вовсе.
Ещё в убунте kkbswitch в нем есть режим, который переключает между двумя последними раскладками. Между русским и английским переключаюсь на Shift+Ctrl, а если надо на армянскую — Ctrl+Alt+3.
Может и без kkbswitch можно как-то настроить, не знаю. Мне и так хорошо :)
У меня такой же роутер, никаких заморочек с его настройкой не было, диск нафиг не нужен. Есть веб-интерфейс, через него всё легко и просто. Единственная проблема — в манах дефолтный логин был указан неправильно (admin вместо Admin), пришлось немного погадать =)
Такой кейс уже не отрабатывает, поскольку стек кавычек сбрасывается вместе со всем остальным контекстом. На выходе даёт
Должен ли он отрабатывать — вопрос сложный. С одной стороны вроде бы логично, но с другой, (а) непонятно, допустимы ли в нормах типографики вложенные цитаты на несколько абзацев, и (б) не хотелось бы, чтобы лишняя кавычка в длинном тексте сдвигала расстановку кавычек в непредсказуемом месте, а то и во всём остальном тексте. Пожалуй, минусы перевешивают, и оставлю-ка как есть, на совести редакторов :)
1. Парсим с помощью lxml.html
2. Проходимся по дереву: каждый абзац типографируется независимо от остальных, граница абзацев — начало и конец блочного тега. Содержимое Некоторых тегов игнорируются.
3. Весь текст разбивается на токены в соотвествии с содержащейся в классе токена регуляркой. При этом каждый токен сохраняет ссылку на место в дереве lxml ElementTree, из которого он взят ([1], [2]).
4. Затем мы проходимся по списку всех токенов и вызываем для каждого функцию преобразования. На входе — итераторы следующих и предыдущих токенов. Итератор возвращает токены-фрагменты текста вне зависимости от тегов, так что при применении правил теги игнорируются.
5. Каждый токен содержит набор правил в виде произвольного кода на питоне, он может смотреть на предыдущих и следующих соседей, может менять, добавлять, удалять соседние токены или самого себя.
6. Записываем изменения в ElementTree
7. Выгружаем ElementTree обратно в HTML.
Например, мой вот этот кейс у вас не проходит, судя по всему (если я всё правильно сделал в демо) — вместо одного неразрывного получается один обычный и один неразрывный.
Еще бросается в глаза смешение работы в текстовом режиме и html. Например, сокращать пробелы до одного и переводы строк до двух максимум имеет смысл для plain text, в то же время, там же есть и теги. Конечно, вряд ли это может создать проблемы, и в некоторых случаях даже подходит, например, для редактора комментов хабра :) Но какой-то червячок внутри меня мне упорно твердит, что разделение методов работы с plain text и html в вебе — это хорошая практика.
Ну и здесь у меня разные издевательства над HTML посреди текста. Вполне вероятные кейсы для данных, поступающих из визивига. Это главная причина, почему я написал свой типограф, потому что сделать такое на регулярках довольно непросто. Неясно, поддерживается ли это у вас, по крайней мере, тестов не вижу…
Это мы какую-то книжку нашли, в которой были описаны правила. В ридми есть ссылка на нее, правда, на другой фрагмент. Найти сейчас ее наверно будет непросто. Я завтра перепроверю по вашей ссылке.
Это lxml виноват :)
chakert опирается на атрибут lang, если он есть. Тут тоже вопрос кейсов, у нас смешанных текстов нет.
Веб-демо нет… pip install chakert lxml
Тесты посмотрю, спасибо.
https://github.com/Harut/chakert
В имеющихся меня не устраивало, что, во-первых правила замены оформлены в виде регулярок, что лично для меня категорически неудобно (у вас, судя по всему, тоже :( ). Особенно, разбираться в чужих регулярках.
Во-вторых, это танцы с бубном вокруг HTML. Он либо эскейпится, а затем раскрывается, либо удаляется, а потом возвращается на место. В первом случае мы получаем, что даже пустой тег, вставленный в неудачном месте, может повлиять на результат, а второй вариант мне не нравится непредсказуемостью, не вызывает доверия.
У меня исходный текст разбивается на токены с использованием регулярок, а затем перебираются все токены и у каждого вызывается метод замены: получает на вход итератор предыдущих и следующих токенов и умеет заменять себя или соседей на любой другой токен.
При этом токены остаются связанными со своими тегами, и при сборке обратно в текст всё само встает на свои места.
Русский + английский. Py2.7, py3.4 (нужно, кстати, освежить...)
Буду рад фидбеку, особенно в виде тест-кейсов :)
Господи, какой же моральный урод. По стопам Сталина идёт.
Если разбивается, начинаем бросать второе яйцо последовательно. Итого, максимум, 14 бросков.
genotip7@…
Потому как решение, базирующееся на другом наборе аксиом может сильно отличаться или не существовать вовсе.
Может и без kkbswitch можно как-то настроить, не знаю. Мне и так хорошо :)
У меня такой же роутер, никаких заморочек с его настройкой не было, диск нафиг не нужен. Есть веб-интерфейс, через него всё легко и просто. Единственная проблема — в манах дефолтный логин был указан неправильно (admin вместо Admin), пришлось немного погадать =)
Статью не дочитал, уж извините.