Как узнать, где браузер разрывает абзац текста
Мне нужно добавить разрывы строк в тех местах, где браузер естественным образом добавляет новую строку в абзац текста.
Например:
<p> Это очень длинный текст \ п, занимающий несколько строк в абзаце. </p>
Это абзац, который браузер решил разбить в позиции \ п
Мне нужно найти эту позицию и вставить <br />
Кто-нибудь знает какие-либо библиотеки или функции JS, которые могут это сделать?
Единственное решение, которое я нашел до сих пор, - это удалить токены из абзаца и наблюдать за свойством clientHeight, чтобы обнаружить изменение высоты элемента. У меня нет времени закончить это, и я хотел бы найти что-то, что уже проверено.
Редактировать: Причина, по которой мне нужно это сделать, заключается в том, что мне нужно точно конвертировать HTML в PDF. Acrobat делает текст более узким, чем браузер. Это приводит к тому, что текст разрывается в разных местах. Мне нужен такой же рваный край и такое же количество строк в преобразованном PDF-файле.
Редактировать:
@dtsazza: Спасибо за продуманный ответ. Нет ничего невозможного в создании редактора макета, который почти точно воспроизводит HTML, который я написал на 99%;)
Приложение, над которым я работаю, позволяет пользователю создавать каталог продуктов, перетаскивая «плитки». Плитки имеют фиксированную ширину, абсолютно позиционированные блоки div, содержащие изображения и текст. Все элементы стилизованы, поэтому размер шрифта фиксированный. Мое решение для поиска \ n в абзаце нормально в 80% случаев, и когда оно работает с заданным параграфом, результирующий PDF-файл настолько близок к экранной версии, что различия не имеют значения. Абзацы имеют одинаковую высоту (до пикселя), изображения заменяются версиями с высоким разрешением, а все растровые изображения заменяются на серверные SVG-файлы.
Единственное различие слабый между моим HTML и PDF состоит в том, что Acrobat визуализирует текст немного более узко, что приводит к немного меньшей длине строки.
Решение Диодеуса по добавлению промежутков и нахождению их координат очень хорошее и должно дать мне местоположение BR. Помните, что пользователь никогда не увидит HTML со вставленными BR - они добавляются, чтобы преобразование PDF создавало абзац точно такого же размера.
Многие думают, что это невозможно. У меня уже есть рабочее приложение, которое создало очень сильно точное преобразование HTML-> PDF наших документов - мне просто нужно лучшее решение для добавления BR, потому что мое решение иногда пропускает BR. Кстати, когда это действительно работает, мои абзацы имеют ту же высоту, что и эквиваленты HTML, что является результатом, который мы ищем.
Если кого-то интересует тип документа, который я конвертирую, вы можете проверить этот снимок экрана:
http://www.localsa.com.au/brochure/brochure.html
Редактировать: Большое спасибо Diodeus - ваше предложение было правильным.
Решение: в моей ситуации было разумнее заключать слова в промежутки, а не в пробелы.
var text = paragraphElement.innerHTML.replace (/ / g, '</span> <span>');
текст = "<span>" + текст + "</span>"; // переносим первое и последнее слово.
Это оборачивает каждое слово в диапазон. Теперь я могу запросить документ, чтобы получить все слова, выполнить итерацию и сравнить позицию y. При изменении y pos добавьте br.
Это работает безупречно и дает мне нужные результаты - Спасибо!
у вас могут быть некоторые проблемы с этим, потому что, если человек изменит размер шрифта, ваши перерывы могут упасть в странных местах
Мне нужно точно преобразовать HTML в PDF. Шрифты в PDF визуализируются немного уже, и это приводит к тому, что текст при преобразовании разрывается в разных положениях.
Вы можете объяснить, что так важно в сохранении неровности края?
Это просто требование проекта. Я работаю над дизайнером брошюр HTML / JS. Конечный продукт (PDF) должен соответствовать версии на экране.
Не существует единой «правильной» экранной версии PDF, с которой можно было бы визуализировать идентично. Разные браузеры и настройки могут отображать шрифты по-разному, что приводит к разным точкам разрыва строки.
Это не имеет значения. Если пользователь использует IE, он хочет видеть разрывы строк в своем PDF-файле в том же положении, что и на экране. Пользователь FF увидит LB в другом положении, но получит другой PDF-файл;)
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 5
Я бы предложил заключить все пробелы в тег span и найти координаты каждого тега. Когда значение Y изменяется, вы находитесь на новой строке.
Но Y? </ Я буду здесь всю ночь>
@Diodeus: Отличная идея даст ему шанс.
Я столкнулся с той же проблемой, когда создавал локальный редактор, используя растровое изображение каждого символа в причудливом шрифте, отличном от браузера. Пришлось самому придумать перенос слов. Фу.
Спасибо за вашу помощь, Диодей, я на полпути к реализации вашей идеи, и она работает как шарм :)
Я не думаю, что у этого будет очень чистое решение, если оно вообще есть. Браузер разместит абзац так, чтобы он соответствовал доступному пространству, при необходимости переводя строки. Учтите, что если пользователь изменит размер окна браузера, все абзацы будут повторно отрисованы и почти наверняка изменят свои позиции разрыва. Если пользователь изменяет размер текста на странице, абзацы будут перерисованы с другими точками разрыва строки. Если вы (или какой-либо скрипт на вашей странице) измените размер другого элемента на странице, это изменит количество места, доступного для плавающего абзаца, и снова - разные точки разрыва строки.
Кроме того, изменение фактической разметки вашей страницы для имитации того, что браузер делает за вас (и делает это очень хорошо), кажется неправильным подходом к тому, что вы делаете. Какую проблему действительный вы пытаетесь решить здесь? Вероятно, есть лучший способ добиться этого.
Редактировать: Хорошо, значит, вы хотите выполнить рендеринг в PDF так же, как «экранную версию». Есть ли у вас номинированная конкретная окончательная версия экрана - с точки зрения размеров окна браузера, пользовательских таблиц стилей, предпочтений шрифта и скорректированного размера шрифта? Важнейшая особенность HTML заключается в том, что в нем намеренно не указывается конкретный макет.. Он просто описывает, что находится на странице, что они собой представляют и где они находятся по отношению друг к другу.
Раньше я видел несколько ошибочных попыток создать некоторый HTML-код, который точно воспроизводил бы печатное объявление, разработанное в чем-то вроде приложения DTP, где важен окончательный абсолютный макет. Эти усилия были обречены на провал из-за природы HTML, и делать это наоборот (как вы пытаетесь) будет даже худший, потому что у вас даже нет окончательной отправной точки для работы.
Исходя из предположения, что это все не в ваших руках и вам придется это сделать в любом случае, я предлагаю отказаться от идеи искажения HTML. Посмотрите на программное обеспечение для преобразования PDF-файлов - если оно хорошее, оно должно предоставить вам несколько вариантов кернинга шрифтов и подобных настроек. Поигравшись с деталями, вы получите что-то, что приблизительно соответствует рендерингу шрифта в браузере и, таким образом, разрывает строки в одних и тех же местах.
В противном случае все, что я могу предложить, - это сделать снимки экрана браузера и проанализировать их с помощью OCR, чтобы определить, где строки разрываются (это не должно требовать очень точного OCR, поскольку вы в любом случае знаете, что такое необработанный текст, по сути, он просто должен подсчитать пробелы). Или, возможно, просто вставьте снимок экрана в PDF, если поиск / выбор текста не имеет большого значения.
Наконец, выполнение этого вручную, вероятно, единственный способ сделать эту работу окончательно и надежно.
Но на самом деле это все еще неправильный, и любые попытки пересмотреть требования будут лучше. Продолжайте подниматься на один шаг в цепочке - Зачем должен ли PDF иметь те же неровные края, что и произвольный рендеринг в браузере? Можете ли вы достичь цели что другим (лучшим) способом?
Ваши предложения звучат как большая работа - я знаю, что можно добавить BR в правильном месте - это просто вопрос использования правильного подхода. Я не уверен, какое решение будет самым быстрым и лучшим, Андрея или Диодея - найти координаты пространств легко и они должны дать точные результаты.
Еще одна вещь, о которой я беспокоюсь при добавлении BR, - это то, сможете ли вы обновить их при изменении размера. Если пользователь изменяет размер своего браузера и т. д., Вам нужно удалить те, которые вы ранее вставили, иначе у них будут странные неестественные разрывы строк в дополнение к собственным браузерам.
Разрывы строк добавляются только к версии, сохраненной на сервере. На стороне клиента разрывы строк добавляются, когда пользователь сохраняет брошюру, а затем удаляются при завершении сохранения.
Звучит как плохая идея, если учесть размер шрифта, установленный пользователем, режим доступности MS Windows и сотни различных мобильных устройств. Позвольте браузеру сделать это - попытка получить точный контроль над рендерингом вызовет у вас только часы разочарования.
Я не думаю, что вы сможете сделать это с какой-либо точностью, не встраивая Gecko / WebKit / Trident или фактически воссоздавая их.
Подход, который я использую в данный момент (удаление жетонов и измерение высоты), работает в 80% случаев, однако у меня нет времени, чтобы его отполировать. Также предложение Diodeus - отличное предложение, которое, я думаю, сработает :)
Может быть, альтернатива: переносите все строки самостоятельно, а не полагайтесь на браузер. Поместите весь текст в предварительные теги и добавьте собственные разрывы строк. По крайней мере, теперь вам не нужно выяснять, куда их поместил браузер.
отличная идея! придется попробовать это.
Вы можете объяснить, зачем вам нужны бра? Разрывы строк - это функция рендеринга, она связана со шрифтом и размером экрана. Кроме того, если вы измените размер окна, разрывы строк, вероятно, будут в другом месте.