Jump to content

Вопросы разработчикам


Recommended Posts

5 часов назад, Евгений777 сказал:

Мне всё равно на ваше отношение, я потребитель продукта

Отказ от моей техподдержки принимается

5 часов назад, Евгений777 сказал:

я поднимаю вопрос возврата денежных средств.

Поднять вопрос твое право, но денег я твоих не видел, поэтому о возврате вопрос не стоит

  • Haha 1
Link to comment
Share on other sites

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

Отказ от моей техподдержки принимается

А вот тут он, действительно, попал!

  • Thanks 2
  • Haha 4
Link to comment
Share on other sites

22 часа назад, oleg25 сказал:

Мне вот в этом месте прям любопытно стало, а перечислите, пожалуйста, отечественные САПР системы того же класса, что nanoCAD. А то может мы чего-то не знаем. Ну, с зарубежными я думаю и так всё понятно. 

Приятно, что вы признали, что по сравнению с зарубежными системами, российское ПО - г*вно.

 

Еще один косяк нанокад - предварительный просмотр слишком долго работает. Полчаса ждать, чтобы посмотреть печатываемый лист - слишком долго российских технологий 21 века

 

Принимайте критику здраво! Если хотите быть лидерами ПО в данном направлении!

image.png

Link to comment
Share on other sites

38 минут назад, Евгений777 сказал:

российское ПО - г*вно

офф.

Нет. подразумевалось, что nanoCAD не просто одно из возможных решений, а что оно безальтернативно. Вы попробуйте посравнивать nanoCAD, например, с китайскими CAD того же класса. Единственный конкурент nanoCAD из всех возможных решений этого же класса - это AutoCAD. Точнее AutoCAD был конкурентом. И это по факту так, еще до санкций так было. У всех других зарубежных решений занять значимую долю российского рынка так и не получилось.

От дальнейшей полемики открещиваюсь. 

  • Like 2
Link to comment
Share on other sites

5 часов назад, oleg25 сказал:

офф.

Нет. подразумевалось, что nanoCAD не просто одно из возможных решений, а что оно безальтернативно. Вы попробуйте посравнивать nanoCAD, например, с китайскими CAD того же класса. Единственный конкурент nanoCAD из всех возможных решений этого же класса - это AutoCAD. Точнее AutoCAD был конкурентом. И это по факту так, еще до санкций так было. У всех других зарубежных решений занять значимую долю российского рынка так и не получилось.

От дальнейшей полемики открещиваюсь. 

Безальтернативно в каком смысле? Что в российским сегменте вообще нет систем? Ну так это не говорит о том, что нанокад хороший

Link to comment
Share on other sites

6 минут назад, Евгений777 сказал:

Ну так это не говорит о том, что нанокад хороший

Так помогите и себе, и разработчикам:

В 15.08.2022 в 15:16, NYO сказал:

Не могли бы приложить/прислать проблемный файл?

 

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Ребят, я просто в шоке от работы в нанокаде. Никто из разработчиков так и не придумал решения проблемы с печатью нанокадом пдф файлов с огромным весом! Ни один из предложенных способов не помог нормально распечатать файл, а файл печатается весом в 1,7 гигов!!!! От любого принтера!!! Я 2 часа потратил ПРОСТО НА ПЕЧАТЬ 1 ФАЙЛА!!! Более того, я не могу сжать распечатываемый файл, даже открыть его не могу, он слишком много весит! Более того,  теперь я не могу его вообще распечатать из-за того, что какой то дебил из разработчиков сделал так, чтобы нанокад сначала пдф файл сохранял в кэш (а сохраняется файл по полчаса!), чтобы потом сохранить файл в папку! Потом он сам открывает свой же распечатанный пдф файл и самому себе запрещает печать!!! Это нонсенс!!! 

 

Вопрос к разработчикам! Как растровое изображение весом 30 МБайт может распечататься в 1 лист весом 800 МБайт??? Мне на мат переходить????

 

Еще раз повторяю для всех кто захочет купить и пользоваться нанокадом - НЕ ПОКУПАЙТЕ СИЁ ДЕРЬМО

Edited by Евгений777
Link to comment
Share on other sites

20 часов назад, Евгений777 сказал:

Вопрос к разработчикам! Как растровое изображение весом 30 МБайт может распечататься в 1 лист весом 800 МБайт??? Мне на мат переходить????

Рискну предположить примерно следующее : исходный растр весом 30Мб (если можно - пример в студию, если нет, то спрошу ТТХ - исходный формат, битность и размеры) - это что-то достаточно жестко пакованое (жпег, тиф - по истеричным выкрикам видно плохо).
Однако, после попадания в нану - мы в нане получили картинко. размером MxN - и, судя по размеру, труколорную.
откуда она такая взялась - да вообще без понятия. мы получили ты самые MxN пикселей. труколорных.
А дальше - ну, хотели как лучше, но вам не понравилось... просто пытались сохранить каждый ваш сраный пиксель.
Никто ж не знал, что вам на них пофигу... хотя, как разработчики (я в том числе) - мы и правда дебилы. Есть, знаете ли определенное уважение к вашим данным - бай дефолт мы пытаемся их сохранить.
Хотя, насчет сжатия растров - мысль интересная, добавить галку "нас много" (в смысле насрать) - фокус невелик...
ресэмплить растры мы умеем, не вопрос! :)

зы : а все-таки интересно, что же там за заветные 30 мегов?

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

10 часов назад, Lion007 сказал:

зы : а все-таки интересно, что же там за заветные 30 мегов?

Тайна сия есть за семью печатями!

  • Like 2
  • Haha 1
Link to comment
Share on other sites

Уважаемые разработчики сего опуса под названием НАНОКАД, можете сказать, почему при многократном ручном вводе одного и того же расстояния выноски от объекта, выноски гуляют? Или опять простой пользователь виноват?

image.png

добавлено через 4 минут
В 03.09.2022 в 06:44, Lion007 сказал:

Рискну предположить примерно следующее : исходный растр весом 30Мб (если можно - пример в студию, если нет, то спрошу ТТХ - исходный формат, битность и размеры) - это что-то достаточно жестко пакованое (жпег, тиф - по истеричным выкрикам видно плохо).
Однако, после попадания в нану - мы в нане получили картинко. размером MxN - и, судя по размеру, труколорную.
откуда она такая взялась - да вообще без понятия. мы получили ты самые MxN пикселей. труколорных.
А дальше - ну, хотели как лучше, но вам не понравилось... просто пытались сохранить каждый ваш сраный пиксель.
Никто ж не знал, что вам на них пофигу... хотя, как разработчики (я в том числе) - мы и правда дебилы. Есть, знаете ли определенное уважение к вашим данным - бай дефолт мы пытаемся их сохранить.
Хотя, насчет сжатия растров - мысль интересная, добавить галку "нас много" (в смысле насрать) - фокус невелик...
ресэмплить растры мы умеем, не вопрос! :)

зы : а все-таки интересно, что же там за заветные 30 мегов?

Меня не интересуют нюансы, я не специалист и не разработчик, мое дело - опробовать продукт и собщить о проблемах

 

Я не понимаю разработчиков. Т.е. опять виноват простой пользователь? Или что? Или я совершенно необосновано заявил о проблеме и должен с терпением печатать один файл по полдня-день? Я не понимаю, я один заявил о проблеме? Другие пользователи, по мнению разработчиков, тоже идиоты?

Link to comment
Share on other sites

Только что, Евгений777 сказал:

почему

Оно само привязалось???

Привязку отключай F3

Link to comment
Share on other sites

Разработчикам нанокада я желаю исключительно успехов в работе и долгосрочного развития! Учитывайте сообщения обычных пользователей, без критики вы не достигнете высот и не усовершенствуете свой продукт до такой степени, когда абсолютное большинство сочтет его лучшим на российском рынке! И я надеюсь, что нанокад станет лучшим продуктом проектировщиков на российском и зарубежном пространстве! Я прошу прощения за мои ругательства, бывает нет терпения, нет возможности ждать, когда заказчик уже требует документацию! Но опять же прошу разрабочиков быть мудрее и идти со временем в ногу!

  • Like 1
Link to comment
Share on other sites

43 минуты назад, Евгений777 сказал:

Меня не интересуют нюансы, я не специалист и не разработчик, мое дело - опробовать продукт и собщить о проблемах

Это пожалуйста. но пример разбухающего растра было бы интересно глянуть. потому что все происходит по какой-то причине. Я вот взял незатейливый TIFF размером 3.5 гигабайта. Пересохранил его в JPG - 125 Mb. И распечатал в PDF - 35 Mb при разрешении 600 DPI, и 135 - при 1200. но на исходные 3.5 Гб - ни разу не похоже...

  • Like 1
Link to comment
Share on other sites

В 03.09.2022 в 05:44, Lion007 сказал:

Однако, после попадания в нану - мы в нане получили картинко. размером MxN - ...

Отдельный респект за терпимость в изложении материала в ЭТОЙ ветке.

Но конкретно по теме: повторная упаковка пересчитанного (фрагмента) изображения в исходный  формат при создании pdf - вполне себе напрашивающаяся фича. Не?

Link to comment
Share on other sites

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

Но конкретно по теме: повторная упаковка пересчитанного (фрагмента) изображения в исходный  формат при создании pdf - вполне себе напрашивающаяся фича. Не?

Пес его знает, если честно... Ситуация, мягко говоря, неоднозначная.
К примеру берем здоровенный растр (МногоПикселей х ЕщеБольшеПикселей) - и втыкаем его в маааленький квадратик. который на выходной PDF-ке будет, скажем, 1х1 см. Имеем полное право, режим секретности этого не запрещает. Что характерно - этот здоровенный растр после перепаковки так и останется здоровенным (в смысле размера в пикселях и байтах) - а вот разрешение у него будет запредельное.

Дальше начинаем его печатать. Если на бумагу - то, вроде как, вопроса нет: есть конкретная железка, она умеет не больше чем, и можно спокойно ресэмплить до разрешения принтера. Сантиметр на сантиметр при разрешении 300 dpi - это примерно 120x120 пикселей. 
Но помимо бумажки - есть еще и вывод в файл (причем даже для физического принтера, который на бумажку печатает) - и тут предположить что с этим файлом будут делать и с каким увеличением разглядывать - крайне затруднительно. Мало ли, может у меня на одной страничке собраны HD-фотографии всех картин Эрмитажа... и я их собираюсь рассматривать с увеличением в 10000%... и в этом случае мне 120x120 не подойдет...

Это первая часть мерлезонского балета. Вторая - это вопрос собственно сжатия. Распространенные форматы - жмут с потерями. Причем гарантии, что распаковав такой файл и запаковав его обратно мы получим то же самое - никакой нет. Просто физика процесса такая - второй раз мы запаковываем не совсем то, что в первый. И тут опять возникает неоднозначность - то ли и так сойдет, то ли нет... 

Так что не все тут так просто - и серебряной пули как-то не видится. Все решения получаются средней паршивости. Но специально никто не вредительствует, так что если вдруг начинает получаться какая-то фигня - то пример в студию и будем смотреть, отчего она такая красивая и как с этим бороться. :)

  • Like 2
Link to comment
Share on other sites

47 минут назад, Lion007 сказал:

Ситуация, мягко говоря, неоднозначная.

Я не сомневаюсь, что вы в полном объеме владеете информацией о сопутствующих проблемах.

И то, что преобразование упаковка-распаковка не является обратимым, тоже известно.

Но обращаю внимание на следующие моменты, что при печати пользователь уже указал а) область печати и б) разрешение.

Исходя из исходного кейса - размер файл кардинально увеличивается - в конечный файл pdf попадает несжатый рисунок M х N х Ц. В данный момент получается, что реализован наиболее простой ДЛЯ ПРОГРАММИСТА способ - "впихнуть" рисунок в pdf как есть (MхNxЦ). Но почему бы не применить упаковку в формате, совпадающем с исходным рисунком, но уже обрезанным по области печати с количеством пикселей, рассчитанным из соотношения области печати и разрешения из параметров печати?

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

  • Like 1
Link to comment
Share on other sites

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

Исходя из исходного кейса - размер файл кардинально увеличивается - в конечный файл pdf попадает несжатый рисунок M х N х Ц. В данный момент получается, что реализован наиболее простой ДЛЯ ПРОГРАММИСТА способ - "впихнуть" рисунок в pdf как есть (MхNxЦ). Но почему бы не применить упаковку в формате, совпадающем с исходным рисунком, но уже обрезанным по области печати с количеством пикселей, рассчитанным из соотношения области печати и разрешения из параметров печати?

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

а что до того, что вздувается - я уже выше писал про растр на 3.5 гига, но повторюсь : исходный TIFF - 3.5 Gb.
он же, сохраненный в JPG - 125 Mb.
PDF-ка при разрешении 300 DPI - 35 Mb. PDF-ка при разрешении 600 - 135 Mb.
как мне кажется, с моими словами вполне коррелирует. а что где вздувается - надо смотреть на примере, который тихонько замылили... :)

  • Thanks 1
Link to comment
Share on other sites

8 минут назад, Lion007 сказал:

а что до того, что вздувается - я уже выше писал про растр на 3.5 гига, но повторюсь : исходный TIFF - 3.5 Gb.
он же, сохраненный в JPG - 125 Mb.
PDF-ка при разрешении 300 DPI - 35 Mb. PDF-ка при разрешении 600 - 135 Mb.
как мне кажется, с моими словами вполне коррелирует. а что где вздувается - надо смотреть на примере, который тихонько замылили... :)

Не знаю в чем,  но чувствую, что меня парят! :prey:

Ну понятно, что во втором случае имеет место сильное сжатие, скорее всего jpeg.

В отличие от исходника, скорее всего голого битмапа (TIF - это контейнер, ничего сам по себе не говорящий о сжатии). PDF, кстати, - это тоже контейнер. Поэтому никто вам-программерам не мешает вставить в него растр в любом упакованном-переупакованном виде. Отсылки к тому, что исходный файл был в таком-то формате - вообще не состоятельны. Не нужно забывать, что исходной задачей является вывод  данных  на принтер, а не  конвертация растра с боязнью чего-то там потерять.  Если производится распаковка в MxNxЦ , то при печати происходит, как я понимаю, создание нового битмэпа со своим M(нов)xN(нов)xЦ(стар или нов) из соотношения области печати и разрешения. А уже этот битмэп можно упаковать, взяв недостающие параметры из исходного растра. Если при распаковке не производится дополнительных преобразований типа накладывания всяких фильтров, то увеличения файла быть не должно, либо оно может быть очень незначительным. 

 

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

  • Like 1
Link to comment
Share on other sites

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

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

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

Ладно, какой-то примерчик вздутия мне Доктор прислал, будем смотреть...

  • Like 1
  • Thanks 1
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...