- Сообщения
- 13 742
- Реакции
- 4 252
Это и прекрасно!а тут уже почти докторские пишутся
Но забавно же.вопрос яйца выеденного не стоит
Это и прекрасно!а тут уже почти докторские пишутся
Но забавно же.вопрос яйца выеденного не стоит
Вот и я придерживаюсь такого способа.Ну а мой способ (левая картинка) управления только "ненужным" цветом более универсальный, как мне кажется.
Т.е., я только задаю только ненужный цвет в 0.2% и оверпринт
С этим все ясно, но ты меня не понял, да ладно.
если кликать на пдф и нажимать контролп, вообще не имеет значения.вопрос яйца выеденного не стоит
головная боль для флексодопечатки, еще их любят в ргб файлах делатьрежимы наложений (лайтен, дакен и пр.)
Ну так обьясни, что конкретно ты имел в виду? Тем более, по условию опыта надо бы не число в строку преобразовывать, а, наоборот, строку (которая в PDF хранится) в число с плавающей точкой и смотреть как округлит.С этим все ясно, но ты меня не понял, да ладно.
Пруфы отметают лишние сомнения. Тем более это не сложнее чем пользоваться калькулятором.что конкретно ты имел в виду
Если вы продолжаете разговор о механизме, который я описывал, то этот механизм допускает любое представление и точность значений в выходном файле (как, впрочем, и во входном) его суть в том, что вычисляются лишь 256 значений выходной величины (с любой "точностью") и, соответственно, на выходе числа могут быть представлены в любом формате, но разных чисел может быть только 256 (то есть без промежуточных величин). Хотя... можно запросто сделать линейную интерполяцию между соседними числами и обеспечить высокую псевдоточность при значительном сокращении вычислений. Но в этом случае исчезла бы ошибка округления. Для проверки можно было бы придумать какое-то преобразование достаточно длинного градиента и посмотреть количество разных значений одной из составляющих цвета. Если их не больше 256, значит работает этот механизм. Вот только я не знаю какое преобразование градиента его включит.Пруфы отметают лишние сомнения.