Мне кажется, не проще. Неоднократно имел опыт разработки похожего специфического ПО. В редких случаях есть возможность сделать "конвертер" формата в "понятный" оборудованию. В основном выходили на вариант написания своего ПО с нуля. Особенно если оборудование не является стандартным, а тоже является свежей разработкой (как и было в большинстве случаев).
Эта задача очень сходна с одной, которую я решал пару лет назад для ковровязальной машины (клиент Thom Engineering, UK). Управляемая электромеханическая составляющая самого станка тоже была нашей разработкой по требованиям клиента. Уникальность заключалась в том, что этот станок имеет гораздо больше возможностей, чем более ранние серии. Можно задавать разную высоту и цвет каждой петли ковра (получается очень красиво, рисунок поверхности ковра в комбинации с полноцветом - это нечно особенное).
Не буду вдаваться в подробности машины, суть в том, что ПО для создания дизайна ковра тоже пришлось делать самостоятельно. Результат получился очень схож с тем, чего желает ТС - тоже матричное поле варьируемого размера и шага сетки, тоже свой формат файлов, тоже трассировка еще и расчет предельных скоростей работы станка; правда много больше настроек (ПО сделал универсальным под все возможные размеры станков, диаметров барабанов, количества игл и других конструктивных особенностей).
Почитал ТЗ - получается, что максимальный размер поля 3000х3000 у.е. (т.к. мин.шаг сетки 0.1), это совсем немного.
Пара вопросов к ТС по пунктам ТЗ:
Хотите интерфейс ПО на одном языке или 2-3-несколько?
3.4.4 - зачем ограничивать количество символов? Ограничение связано с объемом памяти ЧПУ? Тогда ограничивать надо вполне конкретным числом, т.к. этот объем заведомо известен. Либо, если он варьируется - внести такой параметр в ПО.
3.4.16 - имеет смысл добавить табличку со связанным списком символов и дать возможность выбирать символ как на граф.поле, так и в списке. Советую из практических соображений, сталкивался с этим уже и знаю, что облегчает жизнь пользователю.
3.4.19 - не особо вижу смысл в замене. Пользователю проще понять, что нужно просто удалить ненужный символ и на его месте вставить нужный. Учитывая, что в характеристиках каждого символа пользователь может видеть и редактировать все параметры (в т.ч. и базовые координаты), то ничего не стоит увидеть текущее положение, удалить и вставить новый, подправить координаты если надо.
3.5.14 - имеется в виду, что можно назначить цвет каждого символа отдельно или задавать единый цвет всех символов, исполняемых одним инструментом?
3.6.2 - почему ручная трассировка? Вы же пользуетесь какими-то вполне незамысловатыми принципами при ручной трассировке - почему же не дать возможность ПО трассировать самостоятельно на основе того же алгоритма. Это не так сложно как кажется, надо только постараться сформулировать правила. А вдобавок дать возможность ручной правки траектории.
3.7.3 - текстовый документ не имеет свойств шрифта, они применяются программой, которая отображает содержимое текстового файла (блокнот windows/lister/wordpad/akelpad etc.etc.)
3.8.5 - тут скорее всего gif, а не jpeg. Gif больше подходит для рисованной графики. Только вопрос - почему не bmp? Он представляет собой точное попиксельное хранилище изображения и его палитру, без пожатия, но и без потери качества. Лучше уж оставить все варианты (так сказать "на все случаи жизни").
В целом ТЗ вполне понятно и вменяемо, даже избыточно местами. Немного дописать несколько нераскрытых вопросов и можно давать на исполнение.
P.S.: извиняю что многабукоф, но что делать - мне интересна эта тема, только предлагать сходу свои услуги за очередные 100$ "не зная броду" - не готов.
