Пожелания с учётом сборки растровых карт для мобильных телефонов

[ioctl]

При работе с mapsoft для создания плиток для телефонов (программам OSMAnd, Locus Maps ... ) накопились некоторые пожелания. Mapsoft2 я пока детально не смотрел, так что что-то уже может быть неактуально. Напишу в порядке убывания важности на мой взгляд.

1) Крайне желательно, чтобы шаблоны вроде болот и, особенно, вырубок ложились целое число раз на плитку размером 256x256 точек. Это надо для того, чтобы не бросались в глаза границы между плитками. В первом mapsoft при сборке шаблон сначала отрисовывался в растр, а потом ещё раз масштабировался при отрисовке.

2) Очень желательно, чтобы плитка с шаблоном типа вырубка была строго симметричной, что могло не выполнятся в первом mapsoft даже при целом количестве шаблонов в плитке из-за особенностей двойного масштабирования. Это будет выглядеть аккуратно и позволит уменьшить количество задействованных цветов, что уменьшит размер карт на флешке. Для некоторой компенсации данных особенностей я перекомпилировал mapsoft заменив параметр -m7.5 на -m7.88 в make_pics.

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

Вообще, пожелания по шаблонам следующие: чтобы они умещались в плитку 256x256 целое число раз, максимально чёткая отрисовка. Это повысит читаемость, будет красиво и экономно.

3) Было бы хорошо, если подписи вроде "высота над уровнем моря", "номер квартала леса", "название посёлка" будут одинаковым образом выровнены относительно пикселей. А то сейчас получается, что на карте может быть огромное число цифр "1" и все с разным начертанием (из-за растеризации), некоторые из которых выглядят неаккуратно.

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

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

[Vladislav Zavjalov]

On Mon, Feb 24, 2020 at 12:24:32PM +0300, ioctl wrote:
> При работе с mapsoft для создания плиток для телефонов (программам OSMAnd, Locus Maps ... ) накопились некоторые пожелания. Mapsoft2 я пока детально не смотрел, так что что-то уже может быть неактуально. Напишу в порядке убывания важности на мой взгляд.

Спасибо за комментарий. В mapsoft2 все сделано очень похоже (только
настройки вынесены из кода в конфирурационный файл).
Я стараюсь исправлять разные известные проблемы, в частности, ужк учел
твои замечание про отрисовку слишком мелких картинок и про возможность
менять filter для картинок.

Постараюсь сделать пример генерации плиток и поиграться с ним.

> 1) Крайне желательно, чтобы шаблоны вроде болот и, особенно, вырубок ложились целое число раз на плитку размером 256x256 точек. Это надо для того, чтобы не бросались в глаза границы между плитками. В первом mapsoft при сборке шаблон сначала отрисовывался в растр, а потом ещё раз масштабировался при отрисовке.

А не поможет ли просто использовать исходные картинки с размером,
кратным 256? И в mapsoft, и в mapsoft2.

> 2) Очень желательно, чтобы плитка с шаблоном типа вырубка была строго симметричной, что могло не выполнятся в первом mapsoft даже при целом количестве шаблонов в плитке из-за особенностей двойного масштабирования. Это будет выглядеть аккуратно и позволит уменьшить количество задействованных цветов, что уменьшит размер карт на флешке. Для некоторой компенсации данных особенностей я перекомпилировал mapsoft заменив параметр -m7.5 на -m7.88 в make_pics.
>
> 3) Также для увеличения чёткости было бы хорошо, чтобы шаблоны вроде болот ложились на плитку максимально чётко, в частности, чтобы не было полутоновых горизонтальных линий.

То же, не делается ли это просто использованием симметричной и хорошо
выровненной исходной картинки?

> Вообще, пожелания по шаблонам следующие: чтобы они умещались в плитку 256x256 целое число раз, максимально чёткая отрисовка. Это повысит читаемость, будет красиво и экономно.
>
> 3) Было бы хорошо, если подписи вроде "высота над уровнем моря", "номер квартала леса", "название посёлка" будут одинаковым образом выровнены относительно пикселей. А то сейчас получается, что на карте может быть огромное число цифр "1" и все с разным начертанием (из-за растеризации), некоторые из которых выглядят неаккуратно.

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

> 4)Было бы неплохо добавить ночной режим отрисовки карт, как это сделано во многих программах навигации. Тогда на телефон можно будет залить два комплекта и переключаться между ними утром и вечером.

Ну, в mapsoft2 можно просто написать другую конфигурацию для
изготовления растра. Или имеется в виду автоматическое изготовление
ночного режима из обычного (замена цветов по каким-то правилам и т.п.)?

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

Это, кажется, вопрос про ручную/автоматическую расстановку подписей, про
фильтрацию подписей и объектов на мелком масштабе и т.п.
Я, конечно, хочу делать один масштаб. Меня раздражают
разномасштабные карты - после того, как такую фильтрацию подписей и
объкетов сделали в финских топокартах, они стали красивее, но по ним
стало невозможно ходить.
Но какие-то средства для красивого уменьшения масштаба можно
придумывать, конечно.

Слава

[ioctl]

> Постараюсь сделать пример генерации плиток и поиграться с ним.

Спасибо, с радостью помогу с тестированием!

>> 1) Крайне желательно, чтобы шаблоны вроде болот и, особенно, вырубок ложились целое число раз на плитку размером 256x256 точек. Это надо для того, чтобы не бросались в глаза границы между плитками. В первом mapsoft при сборке шаблон сначала отрисовывался в растр, а потом ещё раз масштабировался при отрисовке.
>
> А не поможет ли просто использовать исходные картинки с размером,
> кратным 256? И в mapsoft, и в mapsoft2.

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

Если надо, берусь проэкспортировать/перерисовать все картинки в виде SVG с максимальным сохранением внешнего вида. xfig я так и не осилил, да и cairo его не понимает.

>> 2) Очень желательно, чтобы плитка с шаблоном типа вырубка была строго симметричной, что могло не выполнятся в первом mapsoft даже при целом количестве шаблонов в плитке из-за особенностей двойного масштабирования. Это будет выглядеть аккуратно и позволит уменьшить количество задействованных цветов, что уменьшит размер карт на флешке. Для некоторой компенсации данных особенностей я перекомпилировал mapsoft заменив параметр -m7.5 на -m7.88 в make_pics.
>>
>> 3) Также для увеличения чёткости было бы хорошо, чтобы шаблоны вроде болот ложились на плитку максимально чётко, в частности, чтобы не было полутоновых горизонтальных линий.
>
> То же, не делается ли это просто использованием симметричной и хорошо
> выровненной исходной картинки?

Там так получалось, что в ряде случаев из-за округления пропадала симметрия. Это заметно по шаблонам PNG стандартной сборки mapsoft1, например в вырубках и подобных в центре перекрестья.

>> Вообще, пожелания по шаблонам следующие: чтобы они умещались в плитку 256x256 целое число раз, максимально чёткая отрисовка. Это повысит читаемость, будет красиво и экономно.
>>
>> 3) Было бы хорошо, если подписи вроде "высота над уровнем моря", "номер квартала леса", "название посёлка" будут одинаковым образом выровнены относительно пикселей. А то сейчас получается, что на карте может быть огромное число цифр "1" и все с разным начертанием (из-за растеризации), некоторые из которых выглядят неаккуратно.
>
> Кажется, это легко сделать. Попробую. Наклонным текстам, это, кончено,
> не поможет, а они как раз наименее читаемые.

Наклонным это не поможет, конечно. Но хоть что-то.

>> 4)Было бы неплохо добавить ночной режим отрисовки карт, как это сделано во многих программах навигации. Тогда на телефон можно будет залить два комплекта и переключаться между ними утром и вечером.
>
> Ну, в mapsoft2 можно просто написать другую конфигурацию для
> изготовления растра. Или имеется в виду автоматическое изготовление
> ночного режима из обычного (замена цветов по каким-то правилам и т.п.)?

Боюсь, простой заменой цвета хорошо не выйдет. Например, в OSMAnd и яндекс-навигаторе некоторые цвета меняются сильно, а некоторые меньше. А в результате смешивания на границах объектов получаются новые цвета, которые будет трудно трансформировать.

>> 4) Может быть сложно, но напишу. В mapsoft странно работает отрисовка карт по мере увеличения масштаба (уменьшения приближения). В зависимости от режима или надписи быстро наползают друг на друга, или они становятся мелкими и нечитаемыми даже для названий крупных городов.
>
> Это, кажется, вопрос про ручную/автоматическую расстановку подписей, про
> фильтрацию подписей и объектов на мелком масштабе и т.п.
> Я, конечно, хочу делать один масштаб. Меня раздражают
> разномасштабные карты - после того, как такую фильтрацию подписей и
> объкетов сделали в финских топокартах, они стали красивее, но по ним
> стало невозможно ходить.
> Но какие-то средства для красивого уменьшения масштаба можно
> придумывать, конечно.

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

[Vladislav Zavjalov]

Хотел спросить, получилось ли собрать mapsoft2 и запустить примеры
рендера (в docs/render_*)?

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

Да, картинки svg должно быть несложно сделать средствами Cairo. Попробую.
Еще у меня там есть теперь возможность рисовать всякие штрихи на обрывах
и заборах, и этот же способ работает для рисования векторных картинок
у точечных объектов.

> >> 4)Было бы неплохо добавить ночной режим отрисовки карт, как это сделано во многих программах навигации. Тогда на телефон можно будет залить два комплекта и переключаться между ними утром и вечером.
> >
> > Ну, в mapsoft2 можно просто написать другую конфигурацию для
> > изготовления растра. Или имеется в виду автоматическое изготовление
> > ночного режима из обычного (замена цветов по каким-то правилам и т.п.)?
>
> Боюсь, простой заменой цвета хорошо не выйдет. Например, в OSMAnd и яндекс-навигаторе некоторые цвета меняются сильно, а некоторые меньше. А в результате смешивания на границах объектов получаются новые цвета, которые будет трудно трансформировать.

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

[Vladislav Zavjalov]

On Mon, Feb 24, 2020 at 07:11:42PM +0300, ioctl wrote:
> >> 3) Было бы хорошо, если подписи вроде "высота над уровнем моря", "номер квартала леса", "название посёлка" будут одинаковым образом выровнены относительно пикселей. А то сейчас получается, что на карте может быть огромное число цифр "1" и все с разным начертанием (из-за растеризации), некоторые из которых выглядят неаккуратно.
> >
> > Кажется, это легко сделать. Попробую. Наклонным текстам, это, кончено,
> > не поможет, а они как раз наименее читаемые.
>
> Наклонным это не поможет, конечно. Но хоть что-то.

Сделал такую возможность (см mapsoft2/docs/render_text_pix), поигрался.

- Для горизонтального текста никаких различий не видно. Судя по всему,
правильно работает hinting. Я пытался играть с настройками
hinting/autohint/hintstyle и разными шрифтами, но исходной проблемы
так и не увидел. Но hinting в разных шрифтах может работать
по-разному, кажется, так что, где-то, может, проблема и есть.

- Если текст рисовать в виде контура, то различие видно. Например,
если делать ободок вокруг текста, то он будет выравниваться по
пикселам.

- Для наклонного текста различие видно: буквы по-разному прыгают между
рядами пикселей. Но имеет ли смысл такое выравнивание - не уверен.

[Nikolay Korotkiy]

Кстати, удалось воспроизводимо собрать mapsoft2 с помощью nix, так что сейчас в любом linux дистрибутиве можно использовать (доступно в NUR репозитории), например через:

nix-shell -p nur.repos.sikmir.mapsoft2

(оригинальный mapsoft v1 также доступен там: nix-shell -p nur.repos.sikmir.mapsoft)

Исходники и патчи тут: https://github.com/sikmir/nur-packages/tree/master/pkgs/applications/mapsoft

[Vladislav Zavjalov]

On Thu, Feb 27, 2020 at 02:09:28AM -0800, Nikolay Korotkiy wrote:
> Кстати, удалось воспроизводимо собрать mapsoft2 с помощью nix, так что
> сейчас в любом linux дистрибутиве можно использовать (доступно в NUR
> репозитории), например через:
>
> nix-shell -p nur.repos.sikmir.mapsoft2
>
> (оригинальный mapsoft v1 также доступен там: nix-shell -p nur.repos.sikmir.mapsoft)
>
> Исходники и патчи тут: https://github.com/sikmir/nur-packages/tree/master/pkgs/applications/mapsoft

Спасибо!
Возьму пару вещей из патчей.

А с тестом tmpdir что была за проблема?
Если вот эта: https://github.com/slazav/mapsoft2/issues/48
то она уже исправлена...

[Nikolay Korotkiy]

Пока не разбирался, но на мастере тест не проходит:

## Running test: tmpdir.test
A: Archive: tmp.zip Length Date Time Name --------- ---------- -----
---- 8 02-27-2020 12:26 f1 8 02-27-2020 12:26 f2 8 02-27-2020 12:26 f3 0
02-27-2020 12:26 a/ 0 02-27-2020 12:26 a/b/ 0 02-27-2020 12:26 a/b/c/ 8
02-27-2020 12:26 a/b/c/f4 8 02-27-2020 12:26 a/f5 --------- ------- 40 8
files
B: Archive: tmp.zip Length Date Time Name --------- ---------- -----
---- 8 xxxx-xx-xx xx:xx f1 8 xxxx-xx-xx xx:xx f2 8 xxxx-xx-xx xx:xx f3 0
xxxx-xx-xx xx:xx a/ 0 xxxx-xx-xx xx:xx a/b/ 0 xxxx-xx-xx xx:xx a/b/c/ 8
xxxx-xx-xx xx:xx a/b/c/f4 8 xxxx-xx-xx xx:xx a/f5 --------- ------- 40 8
files
make[2]: *** [../Makefile.inc:87: tmpdir.test.passed] Error 1
make[2]: Leaving directory '/build/source/modules/tmpdir'
make[1]: *** [../../modules/Makefile.inc:63: make_deps] Error 2
make[1]: Leaving directory '/build/source/programs/ms2conv'
make: *** [Makefile:22: ms2conv] Error 2

--
Best regards,
Nikolay

[Nikolay Korotkiy]

И если кому интересно, там же можно собрать готовые img для хребтовок и карты подмосковья:

nix-build -A nur.repos.sikmir.slazav-hr
nix-build -A nur.repos.sikmir.slazav-podm

[Nikolay Korotkiy]

C test_img пока тоже проблема:

## Running test: ms2conv.test_img
Files test_data_img/out1.pdf and tmp.pdf differ
different files: test_data_img/out1.pdf tmp.pdf:
Binary files test_data_img/out1.pdf and tmp.pdf differ
make[1]: *** [../../modules/Makefile.inc:90: make_tests] Error 1

make[1]: Leaving directory '/build/source/programs/ms2conv'
make: *** [Makefile:22: ms2conv] Error 2

[slazav]

Про tmpdir.test: не поможет ли в `tmpdir.test.script` перед unzip -l вставить что-то типа `LC_ALL=C` ?

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

С картинками я пока не придумал, как правильно делать тесты, чтобы они везде одинаково работали. Так что пока придется отключать, видимо.Это, кстати, можно делать, поставив переменную окружения SKIP_IMG_DIFFS=1. Я так собираю в Altlinux под разные архитектуры.

[Nikolay Korotkiy]

LC_ALL=C не помогает, с ним как раз дата в формате xx-xx-xxxx. А какая у
тебя локаль где получаешь xxxx-xx-xx?

> --
> You received this message because you are subscribed to the Google
> Groups "mapsoft2" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsoft2+u...@googlegroups.com
> <mailto:mapsoft2+u...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mapsoft2/15e37c5d-21a2-4bcf-a667-c1d5ab431216%40googlegroups.com
> <https://groups.google.com/d/msgid/mapsoft2/15e37c5d-21a2-4bcf-a667-c1d5ab431216%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Best regards,
Nikolay

[slazav]

 У меня так:

$ locale
LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_NUMERIC=C
LC_TIME=C
LC_COLLATE="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES=C
LC_PAPER="ru_RU.KOI8-R"
LC_NAME="ru_RU.KOI8-R"
LC_ADDRESS="ru_RU.KOI8-R"
LC_TELEPHONE="ru_RU.KOI8-R"
LC_MEASUREMENT="ru_RU.KOI8-R"
LC_IDENTIFICATION="ru_RU.KOI8-R"
LC_ALL=

То есть, LC_TIME=C. Установка LC_ALL=С ничего не меняет.

Может, unzip разный?

$ unzip -v
UnZip 6.00 of 20 April 2009, by ALT Linux Team.  Original by Info-ZIP.

[Nikolay Korotkiy]

Проверил в Archlinux, там unzip дату в формате xxxx-xx-xx выдает, в
NixOS же только в xx-xx-xxxx и LC_TIME никак не меняет дела. Версии и
опции сборки unzip одинаковые. Непонятно.

> --
> You received this message because you are subscribed to the Google
> Groups "mapsoft2" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsoft2+u...@googlegroups.com
> <mailto:mapsoft2+u...@googlegroups.com>.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/mapsoft2/9494dbea-6b65-4f99-ad26-3d5dd218f918%40googlegroups.com
> <https://groups.google.com/d/msgid/mapsoft2/9494dbea-6b65-4f99-ad26-3d5dd218f918%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Best regards,
Nikolay

[ioctl]

На текущий момент я постарался максимально точно подогнать SVG под PNG по базовой геометрии, картинки получены экспортом из FIG с серьёзной доработкой напильником. От FIG они не зависят.

Если с SVG в mapsoft2 получится, можно попробовать подкорректировать файлы для повышения качества наложения и отрисовки с учётом высказанных предложений.

 

 

24.02.2020, 12:24, "ioctl" <io...@ya.ru>:

[ioctl]

На текущий момент я постарался максимально точно подогнать SVG под PNG по базовой геометрии, картинки получены экспортом из FIG с серьёзной доработкой напильником. От FIG они не зависят.

Если с SVG в mapsoft2 получится, можно попробовать подкорректировать файлы для повышения качества наложения и отрисовки с учётом нижеописанного.

 

24.02.2020, 12:24, "ioctl" <io...@ya.ru>:

При работе с mapsoft для создания плиток для телефонов (программам OSMAnd, Locus Maps ... ) накопились некоторые пожелания. Mapsoft2 я пока детально не смотрел, так что что-то уже может быть неактуально. Напишу в порядке убывания важности на мой взгляд.

[slazav]

Да, я уже понял, что автоматическая генерация из fig получается кривой. И, наверное, твои svg надо вернуть.

Сейчас svg в mapsoft работает (и сейчас там в примере штриховки делаются из svg).

Но получается, что svg все равно надо прогонять через растр. Я сейчас загружаю картинки в родном размере, потом они уже масштабируются как надо. Может быть, стоит при каждом рисовании загружать заново, уже зная, в каком маштабе их надо рисовать.

[ioctl]

!

 

Те 2 идентичных письма я отправлял ещё 02.03.2020, но они где-то гуляли так что возможно и это письмо сильно припозднится.

 

 

Вроде как подгонкой под растр должен заниматься Cairo. Надо только загрузить картинку и сказать, заполнить такую-то область, так что сложностей быть не должно... теоретически.

 

Отдельный момент -- сохранение приемственности восприятия относительно mapsoft. Там так получалось, что картинки имеющее изначальное соотношение сторон 2:1 (вырубки), в png имели уже другое соотношение. Но это пол-беды.

 

Для заполнение 256 было бы идеально, чтобы шаблон вырубки ложился на кратное двум число точек. В mapsoft1, если я правильно помню, ширина шаблона 46 точек. Если в ms2 вырубка будет 32 или 64 точки, это различие будет бросаться в глаза. Как вариант, можно отрисовывать шаблон шириной 256/6 == 42.(6) точек -- это очень близко к 46. Но это может чуть хуже выглядеть (хотя лучше, чем сейчас), плюс будет больше смешанных цветов, а значит больший вес загруженных карт и более тяжёлая обработка.  

 

 

 

И ещё новое пожелание -- в популярных программах навигации рано или поздно появится поддержка карт в SVG (в том числе плиток). Поскольку внутри mapsoft2 данные и так в векторном формате, хорошо было бы не обрубить концы и оставить возможность в будущем сделать отрисовку карт и плиток в этот SVG. Я так понимаю, Cairo всё равно во что рисовать.

 

 

03.03.2020, 13:39, "slazav" <vl.za...@gmail.com>:

Да, я уже понял, что автоматическая генерация из fig получается кривой. И, наверное, твои svg надо вернуть.

 

Сейчас svg в mapsoft работает (и сейчас там в примере штриховки делаются из svg).

 

Но получается, что svg все равно надо прогонять через растр. Я сейчас загружаю картинки в родном размере, потом они уже масштабируются как надо. Может быть, стоит при каждом рисовании загружать заново, уже зная, в каком маштабе их надо рисовать.

 

 

--

You received this message because you are subscribed to the Google Groups "mapsoft2" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mapsoft2+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mapsoft2/a2fb753f-a822-41f1-a215-0c17032905e6%40googlegroups.com.

[slazav]

Два письма почему-то попали в спам, но мне пришло сообщение и я их оттуда добыл.

Некоторая проблема в том, что Cairo умеет писать в svg, но не умеет из него читать. Для этого приходится пользоваться сторонней библиотекой (librsvg), и рендерить картинку в Cairo::ImageSurface. Наверное, можно хранить хэндлеры librsvg вместо паттернов cairo и рендерить перед рисованием. Или вообще всю картинку читать перед рисованием.

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

[ioctl]

Ещё одна мысль пришла, правда, не знаю насколько это просто сделать, и насколько нужно.

 

Итак, есть файлик с крестиком (cross.svg) с соотношением сторон 2:1 . Если мы его экспортируем в png с разрешением кратным двум (что очень желательно), то уголки ближе к центру неизбежно лягут на линию между центрами пикселей, таким образом, этот уголок отрисуется двумя пикселями, а не на одним. См. cross-orig.png под увеличением. Только надо настроить просмотрщик, чтобы при увеличении он не интерполировал пиксели, а показывал их большими квадратиками.

 

А вот если при экспорте сдвинуть центр на пол-пикселя по диагонали (cross-shift.png), то уголки будут отрисованы одним пикселем, что несколько лучше выглядит.

 

Конечно, на печати это вообще не заметно, однако при просмотре с телефона при приближении будет видно.

 

 

Сходу видны следующие потенциальные проблемы:

 

1) Усложнение алгоритма отрисовки.

 

2) Размер файла увеличивается за счёт усложнения рисунка: cross-orig.png весит 732 байт, cross-shift.png весит 1010 байт, что отчасти объясняется "граничным эффектом". Но и обрезанная на один пиксель по двум направлениям картинка cross-shift2.png весит 819 байт. Строго говоря, исходная векторная картинка сделана мной не совсем верно, и размеры png должны быть заметно меньше, но тенденция останется.

 

3) Плитка полностью заполненная шаблоном сохраняет способность создавать периодические рисунки, но теряет осевую симметричность.

 

 

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