Перейти к содержанию

Проблемы с печатью после обновления нанокад 21.01 ver.5851


Рекомендуемые сообщения

6 минут назад, EdwardSt сказал:

Форматка (точнее две -для альбомного и портретного расположения разные, кстати, почему?)

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

7 минут назад, EdwardSt сказал:

добавляется только при нажатии кнопки

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

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

 

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, doctorraz сказал:

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

и чо?

Формат то один! Просто используется с разными параметрами.

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

Но при таком подходе и замена пепельницы может из анекдота перекочевать в реалии жизни.

Ссылка на сообщение
Поделиться на другие сайты
32 минуты назад, EdwardSt сказал:

Формат то один

В случае с нано формат парный, т.е. видим один, но их два.

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

Здесь это исключено

 

добавлено через 1 минуту

Вернее лркальное имя формата одно, а каннонических два  два и тех и этих

Изменено пользователем doctorraz
Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, doctorraz сказал:

В случае с нано формат парный, т.е. видим один, но их два.

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

 

Эксперимент включал следующие шаги:

1. Создал новый формат в файле с единицами в дюймах , а потом в файле с единицами в мм

Спойлер

image.png.512fd74bf68844f30fd50d94bcbff6c7.png

 

2. В реестре для них создались по паре веток в реестре:

Для формата 3,54 х 7,29 дюйма

Спойлер

image.png.d24f1e298ce0b1e0bdd32627ac78ada1.png

 

и

Спойлер

image.png.0cc8d2f9e6aabfdb0e6c3a8e0a5f2ae3.png

 

Для формата 1000х1000мм

Спойлер

image.png.03c00202fe2f81d7416fd56afef37e2c.png

 и портрет с такой же строкой ключа m_ptSize, как и для альбомной (извиняюсь, рисунка уже нет, см. ниже)

 

3. Далее совершил не совсем обычное действо, но которое в принципе можно сопоставить с программным изменением какого-либо ключа в реестре.

А именно заменил значение ключа m_ptSize в ветке Paper 96 (соответствующей портрету 1000х1000) значением из ветки 94 (портрет из 3,54 х 7,29 дюйма)

Итого стало:

Спойлер

image.png.cc12555ac49b71df4094a228a744fb90.png

 

4. Вот как выглядит теперь эта конструкция

Спойлер

image.thumb.png.f9d18e67b2183fdd16332159b8c64a82.png

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

Отмечу, что в ключе m_ptSize расположена информация о размерах в шестнадцатеричном формате.

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

Глубже с форматом хранения не стал, т.к. это к эксперименту не относится.

 

4. Попытка вывода на печать квадрата с диагональю приводит к РАЗЛИЧНЫМ результатам в зависимости от ПОСЛЕДОВАТЕЛЬНОСТИ установки параметров печати. 

Спойлер

image.thumb.png.46e08b35b3f8d8c9af7d2ef92e727994.png

 

5. Маршрут №1
 выбираем формат 1000х1000

Спойлер

image.thumb.png.c1e85e1b4fa9934b43c4af520d143e17.png

и при переключении на книжную ориентацию

Спойлер

image.thumb.png.b7c6a7e70d491371a957e15b0d3be9ee.png

 

Результат в файле pdf соответствует параметрам предварительного просмотра,  лист сформировался

Спойлер

image.png.ffb93d5e34892c79e259ef5541b29b0d.png

 

6. Маршрут №2. Меняем последовательность переключения на портрет 1000х1000. А именно

После начального диалога (шаг 4) переключаем на 

Спойлер

image.thumb.png.fde1e13a9047e0526490c440a93626f8.png

и

Спойлер

image.thumb.png.b9ceb46810a84b10869dfd97590b0d22.png

В принципе, в этот момент у нас должна была получиться картинка, как на шаге 5, но она совсем другая!

 

Результат в файле pdf так же соответствует параметрам предварительного просмотра,  лист сформировался

Спойлер

image.png.6d87ad2d76d89d6639e6dd8bdf07eb32.png

 

 

Итоги "расследования":

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

 

2. Сохранить параметры печати на маршруте №1 не получится, т.к. окончательно установленные параметры печати не будут коррелироваться с параметрами ветки реестра (все-таки проверка смежной ветки хоть и поздно, но производится). 

 

3. Для проектировщика эти манипуляции с форматами вообще остаются за кадром.

Они его не касаются, пока все работает штатно, в реестр никто не лезет, никаких сторонних утилит печати, манипулирующих форматами, не применяется.

 

4. Если что-то на каком-то этапе пошло не так (ошибки программирования, сбой работы приложения), то исправление ситуации силами проектировщика будет под большим вопросом, т.к. штатных средств проверки корректности форматов просто нет.

 

Вывод:

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

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

 

Ссылка на сообщение
Поделиться на другие сайты
21 минуту назад, EdwardSt сказал:

штатных средств проверки корректности форматов просто нет.

убиваешь ветку принтера, при первом обращении к принтеру нана создаст ветку заново (возможно даже корректно)

----------

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

т.е. нет головняка как повернуть формат, нана сам знает как

 

Изменено пользователем doctorraz
Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, doctorraz сказал:
23 минуты назад, EdwardSt сказал:

штатных средств проверки корректности форматов просто нет.

убиваешь ветку принтера, при первом обращении к принтеру ...

т.е., убийство ветки принтера - это штатное средство? Серьезно?

 

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

Изменено пользователем EdwardSt
Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, EdwardSt сказал:

т.е., убийство ветки принтера - это штатное средство? Серьезно?

просто средство

тут многие вещи приходиться делать нетрадиционно

это нано

------------

в принципе до тех пор пока нанодев не поломал принтеры (этим летом) нужды в штатном или нештатном средстве правки форматов лично у меня совсем не возникало

Ссылка на сообщение
Поделиться на другие сайты

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

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

А убийство ветки принтеров становиться почти естественным...

Ссылка на сообщение
Поделиться на другие сайты

У меня вообще даже принтер не HP, а EPSON L1300 А3 формата, та же фигня с тормозами, но только когда много листов в проекте

Ссылка на сообщение
Поделиться на другие сайты
  • 3 недели спустя...

Вопрос с зависанием так и не решился? Я печатаю в doPDF11. После обновления началось. Тормоза начинаются сразу после нажатия кнопки печать. Первое время было около минуты, терпимо. Теперь регрессирует, может висеть по 10-20 минут. Я думал с компом, что то не то. А тут вон чего. Что делать то, а?

Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, Алексей Водомер сказал:

Вопрос с зависанием так и не решился? Я печатаю в doPDF11. После обновления началось. Тормоза начинаются сразу после нажатия кнопки печать. Первое время было около минуты, терпимо. Теперь регрессирует, может висеть по 10-20 минут. Я думал с компом, что то не то. А тут вон чего. Что делать то, а?

Добрый вечер! Уже работаем над устранением проблемы с зависанием при печати, в новой версии печать будет работать быстрее.

Ссылка на сообщение
Поделиться на другие сайты
  • 3 недели спустя...
В 03.12.2021 в 09:06, doctorraz сказал:

Нет его уже несколько лет

Кто ищет - тот найдёт :) Я уже давно на нём сижу - лучшее, что можно придумать для печати на любые принтеры/плоттеры. Всё через PDF.

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
  • Расскажите друзьям

    Нравится Официальный форум компании Нанософт? Расскажите друзьям!
×
×
  • Создать...