Jump to content

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


Recommended Posts

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

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

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

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

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

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

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

 

Link to comment
Share on other sites

1 час назад, doctorraz сказал:

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

и чо?

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

 

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

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

Edited by doctorraz
Link to comment
Share on other sites

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 разных независимых (с точки зрения места хранения в ветках реестра) может приводить к искажениям функциональности, т.к. реестр является совместно используемым ресурсом, а, значит, нет никакой гарантии в неизменности данных в результате ошибочных манипуляций, сбоев при выполнении и т.п.. 

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

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

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

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

----------

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

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

 

Edited by doctorraz
  • Like 1
Link to comment
Share on other sites

5 минут назад, doctorraz сказал:
23 минуты назад, EdwardSt сказал:

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

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

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

 

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

Edited by EdwardSt
  • Like 2
Link to comment
Share on other sites

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

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

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

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

это нано

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

5 часов назад, Алексей Водомер сказал:

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

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

Link to comment
Share on other sites

  • 3 weeks later...
В 03.12.2021 в 09:06, doctorraz сказал:

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

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

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Tell a friend

    Love Официальный форум компании Нанософт? Tell a friend!
×
×
  • Create New...