alx.bilous

так уж получилось что func здесь зарезервированное слово cdecl> explain char(*(*fffff(void))[3])(void) declare fffff as function (void) returning pointer to array 3 of pointer to function (void) returning char

Я не знаю, упоминали ли здесь легковесные редакторы https://code.visualstudio.com или sublime, они намного болше чем нужно новичку и намного меньше тяжелых иде, функциональность которых нужна не так уж и часто.

Если вам так нравится разбирать сложные декларации, cdecl существует уже лет как 20, даже веб интерфейс есть https://cdecl.org

А здесь и не нужна идеальная форма вовсе. Если привести в качестве примера dvd диск, где при записи подобные отклонения намного превышают разрешение печати на пленку, то этой проблемой можно пренебречь. Кстати, сразу возникла идея, подойдет ли для кустарных условий фокусируемая лазерная головка от dvd привода? Мы будем иметь возможность точно корректировать фокус, возможно получится как-то использовать войск-койл, на первый взгляд кажется что получится сдвигать луч в сторону, тем самым повышая разрешение по второй оси. будет ли смысл от встроенного сенсора в качестве контроля экспонирования? Интересно как вы решаете ситуацию когда при включении рабочая грань выбирается случайно, и в результате это будет влиять на абсолютный размер линий на пленке а нужен ли здесь фапч вовсе? Почему не пойти обратным путем и формировать интервал включения выключения лазера в зависимости от текущих скорости и грани? Просто предположение. И все же интересно, как будет влиять мощность лазера на качество линии? Мне кажется, подобные вещи делаются не для коммерческого подхода, ;) а повысить точность достаточно интересная задача.

Думаю, на эту тему все уже давно придумано, нужно только хорошо поискать http://www.precisionmechatronicslab.com/wp...016/06/main.pdf

Было бы действительно здорово увидеть картинку без интерполяции, и jpeg не самый лучший формат для представления подобных данных. Может есть какая то возможность сфотографировать через микроскоп? потому что все дело тайминге выдержки и соотношения мощности лазера. Мне кажется если учитывать что рисуется не идеальная точка, а объект большего диаметра с неравномерной яркостью, учитывать свойства экспозиции материала, и рисовать картинку учитывая наложение подобных "кружков" то можно получить значительно лучший результат.

Мне и правда нужно было упоминать что строка девять и строка восемь это тот случай когда "массив поведет себя иначе чем указатель"?

https://ideone.com/SLqzMw

60мкм это в три раза меньше чем 1200dpi

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

Это нормальный код для этой задачи. Использовать инлайн функции совершенно нормальная практика для подобных целей, например можете сделать так же как в этом примере https://github.com/threatstack/libldns/blob...s/util.h.in#L81 Использовать набор функций ldns_read_uint32, ldns_read_uint16, ldns_read_uint8 для знаковых соотвественно.

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

ну можно и проще, все что надо это найти базовую грань, самую большую или самую малую и привязать заданные коэффициенты поправки длины интервала(поскольку они не изменяются, можно подкорректировать один раз), мне кажется принтер так и делает при нормальной работе. https://patents.google.com/patent/US5754215A/en

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

гцц понимает, keil понимает, аврка понимает, iar вроде тоже как. Значит практически все компиляторы понимают? И вообще, "*" стандарт явно определяет. Ну и то что маргинальные компиляторы не могут в этот формат, никак не означает что нельзя использовать эту функцию