Есть необходимость использовать при печати из report неразрывный пробел (CHR(160)) и неразрывный дефис (CHR(173)).
Уперся в тупик: для SET REPORTBEHAVIOR 90 неразр.пробел работает, а дефис нет, для SET REPORTBEHAVIOR 80 наоборот

konst005_
Есть необходимость использовать при печати из report неразрывный пробел (CHR(160)) и неразрывный дефис (CHR(173)).
Уперся в тупик: для SET REPORTBEHAVIOR 90 неразр.пробел работает, а дефис нет, для SET REPORTBEHAVIOR 80 наоборот

А если попробовать шрифты не по умолчанию? Скажем тот же Arial Unicode?

Использую в этой форме Courier New, 10, B, 204
Попробовал Arial Unicode, 10, B, 204 - ничего не изменилось
Т.е. неразрывный пробел для SET REPORTBEHAVIOR 80 в репорте разрывается (переносится на другую строку)

Цитата:

неразр.пробел работает, а дефис нет

0xAD - Soft Hyphen, а не No-Break Hyphen.

Soft Hyphen:

Цитата:

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

Я уж не знаю, как в Фоксе это должно/не должно работать, но на "неразрывность" это определение мало похоже.

Опишите словами, какого поведения (что должно происходить) вы ожидаете от принудительного внедрения этого символа в строку.

akvvohinc
Опишите словами, какого поведения (что должно происходить) вы ожидаете от принудительного внедрения этого символа в строку.

В тексте используются обозначения нормативных документов типа "ГОСТ 8.393-2010". Переносить нельзя ни по точке ни по дефису. Точку заменяю на CHR(160), дефис на CHR(173).
При печати через Ворд все работает!(При выгрузке полученного текста из FoxPro в Word)
Но надо печатать с помощью report. А тут засада, как уже писал: для SET REPORTBEHAVIOR 90 неразр.пробел работает, а дефис нет, для SET REPORTBEHAVIOR 80 наоборот.
Может я заработался и что-то делаю не так. Нужна помощь!



Исправлено 2 раз(а). Последнее : konst005_, 22.09.20 06:37

konst005_

akvvohinc
Опишите словами, какого поведения (что должно происходить) вы ожидаете от принудительного внедрения этого символа в строку.

В тексте используются обозначения нормативных документов типа "ГОСТ 8.393-2010". Переносить нельзя ни по точке ни по дефису. Точку заменяю на CHR(160), дефис на CHR(173).
При печати через Ворд все работает!(При выгрузке полученного текста из FoxPro в Word)
Но надо печатать с помощью report. А тут засада, как уже писал: для SET REPORTBEHAVIOR 90 неразр.пробел работает, а дефис нет, для SET REPORTBEHAVIOR 80 наоборот.
Может я заработался и что-то делаю не так. Нужна помощь!

Может быть еще попробовать с кодовой страницей что-то? Какая там стоит.

CODEPAGE=1251
COLLATE=RUSSIAN

konst005_
CODEPAGE=1251
COLLATE=RUSSIAN

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

Набросал тестовую прогу
Попробуйте, может это только у меня косяк.

Можно на время заменить не на nbsp, а на видимую кракозябру. Т.е. проверить, попадает ли в принципе псевдосимвол на выход, на принтер

konst005_
может это только у меня косяк.

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

Вообще-то неразрывный дефис — это CHR(45), а не CHR(173), как уже выше намекнул akvvohinc

Да мне кажется, нет какого-то особого смысла использовать все это дело с переносами вообще.
Поскольку это требует лишней предварительной замены, вставки всех эти переносов и прочего. Еще и с учетом SET REPORTBEHAVIOR.
А зачем?!
Старый добрый способ форматирования текста куда как проще тут подошел бы.
Т.е. сканируем текст, скажем по 40 символов на строку. И ставим через каждые 40 символов знак переноса строки. Можно с учетом пробелов, границ слов.
При этом проверяя наличие некоей заданной конструкции типа указанной у автора "ГОСТ 8.393-2010". И если она обнаруживается, всего лишь ставим знак переноса перед ней. Начиная новый отсчет уже с нее.
Все это делается в принципе вообще элементарно, просто написать такую функцию обработки текста и пропускать через нее.
При этом ничего совершенно не привязывается к установкам SET REPORTBEHAVIOR.
Зачем что-то мудрить, когда можно сделать проще.





Исправлено 2 раз(а). Последнее : Crispy, 23.09.20 10:30

ry
Вообще-то неразрывный дефис — это CHR(45), а не CHR(173), как уже выше намекнул akvvohinc

CHR(45) не помогло
Для SET REPORTBEHAVIOR 80: CHR(160) игнорирует (переносит), CHR(45) не переносит
Для SET REPORTBEHAVIOR 90: CHR(160) не переносит, CHR(45) игнорирует (переносит)
При выгрузке документа в WORD символ CHR(45) работает как обычный дефис

Crispy
Да мне кажется, нет какого-то особого смысла использовать все это дело с переносами вообще. Поскольку это требует лишней предварительной замены, вставки всех эти переносов и прочего. Еще и с учетом SET REPORTBEHAVIOR.
А зачем?!
Старый добрый способ форматирования текста куда как проще тут подошел бы.
Т.е. сканируем текст, скажем по 40 символов на строку. И ставим через каждые 40 символов знак переноса строки. Можно с учетом пробелов, границ слов.
При этом проверяя наличие некоей заданной конструкции типа указанной у автора "ГОСТ 8.393-2010". И если она обнаруживается, всего лишь ставим знак переноса перед ней. Начиная новый отсчет уже с нее.
Все это делается в принципе вообще элементарно, просто написать такую функцию обработки текста и пропускать через нее.
При этом ничего совершенно не привязывается к установкам SET REPORTBEHAVIOR.
Зачем что-то мудрить, когда можно сделать проще.

Ваш способ подходит только для пропорционального шрифта при условии, что мы знаем сколько символов будет в строке. А если шрифт по требованию заказчика непропорциональный? А если строки разной длины и мы не знаем заранее какой?
Хотя в целом Вы правы, способ рабочий. Я такой использовал еще для Foxpro for DOS



Исправлено 1 раз(а). Последнее : konst005_, 24.09.20 06:45

konst005_
А если шрифт по требованию заказчика непропорциональный? А если строки разной длины и мы не знаем заранее какой?

В принципе это тоже вычисляемо функциями TXTWIDTH() и FONTMETRIC().
Думаю не слишком сложно можно также и с переменной длиной решить. Тем более, использование рипорта все равно ведь накладывает уже ограничения на длину.
Основной же плюс старого метода, на мой взгляд, так это в большей предсказуемости результата.
В то время, как все эти "мягкие переносы", увы, как выясняется для случая с рипортами, не так однозначны и просты.

Пардон, чет не догоняю.
Если точку оставить на месте и обычный минус тоже, то при se repo 80 рвётся после ГОСТ по пробелу.
Но на это в ТЗ нет запрета.

Taran
Пардон, чет не догоняю.
Если точку оставить на месте и обычный минус тоже, то при se repo 80 рвётся после ГОСТ по пробелу.
Но на это в ТЗ нет запрета.

Пробел после ГОСТ заменяется на CHR(160). Переноситься не должен.



Исправлено 1 раз(а). Последнее : konst005_, 24.09.20 14:15

konst005_

Taran
Пардон, чет не догоняю.
Если точку оставить на месте и обычный минус тоже, то при se repo 80 рвётся после ГОСТ по пробелу.
Но на это в ТЗ нет запрета.

Пробел после ГОСТ заменяется на CHR(160). Переноситься не должен.

Ну заменить тогда его на символ подчеркивания.
Это всяко лучше чем точку после 8 на пробел менять

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

Crispy
В принципе это тоже вычисляемо функциями TXTWIDTH() и FONTMETRIC().

Я когда-то тоже занимался подобным - пытался определить длину строки символов для непропорционального шрифта.
И помнится, наиболее подходящим (более точным) оказался следующий - создавать Label (.Autosize=.T.) с теми же характеристиками шрифта на форме, выводимой (она должна быть видимой) за пределами видимой части экрана ("невидимая форма") и возвращать Label.width.

FONTMETRIC() не мог обеспечить достаточную точность во всех случаях.

Но это лишь мои воспоминания, в деталях я уже могу ошибаться за давностью лет.