Конечно, сделать пакет с помощью Fontinst --- это почти идеальное решение. Однако не без недостатков. Главный в том, что это уж очень фундаментально, нужно все-все описать, что требует некоторой не очень маленькой подготовки как для работы с FontInst, так и с процессами перекодировки. Вероятно не менее 2-х лет. Есть ещё, как минимум, одна проблема, но о ней позже. А сейчас о том, как можно с помощью afmtoenc и ttfencinst быстренько все подключить и без помощи гуру обойтись. Ведь ТеХ --- это, в идеале, система, где все должно быть сделано cамим автором. ;-)

В Linux и т.п. запускаем сценарий

for i in ot1 t1 ts1 t2a t2b t2c t2d; do
for k in *ttf;do
  ttfencinst $k $i n
done
done
cat *4map >ptsans.map

В первую строку можно добавить нужные кодировки T5 (вьетнамский), LGR (греческий), OT2 и т.п. Конечно можно и убирать ненужные. Запускать сценарий нужно из каталога с устанавливаемыми ttf-шрифтами.

Все! Посмотрите, если нужно, pdf-карты и можно работать. В pdflatex-документе нужно только не забывать вставить в преамбулу \pdfmapfile{ptsans.map}. Получилось, как говориться, "грязно и быстро". К шрифтам получаем доступ только при помощи неудобной команды \newfont и последующих всегда явных установок шрифта, например, после \newfont{PTsansbxTEN}{PTS75F-t2a at 10pt} можно будет пользоваться \PTsansbxTEN, т.е. к названию исходного ttf-файла добавляется через дефис кодировка. Естественно текущая кодировка в контексте и выбранная командой переключения шрифта должны совпадать и для каждого размера --- своя команда.

Сделать все "почище" можно, только сделав fd-файл для каждой выбранной кодировки. К сожалению, из-за огромного многообразия способов идентификации шрифтов сделать это полностью автоматически практически невозможно. Приближением к идеалу тут была бы экспертная система с эвристиками и дополнительными вопросами к пользователю... Однако, общий объем ручной работы тут невелик --- сложнее однозначно идентифицировать по ТеХ-категориям шрифт и тем более систему шрифтов. Можно помочь себе сценариями, например, awk. Поставим в новую строку после 1-го for

awk 'BEGIN {i="'$i'";s=toupper(i)
print "\\ProvidesFile{"i"ptsans.fd}\n  [day-month-year v1.0 PT Sans at "s" encoding]"
print "\\DeclareFontFamily{"s"}{ptsans}{}"}'>${i}ptsans.fd

и в новую строку после ttfencinst

awk 'BEGIN {i="'$i'";s=toupper(i)
print "\\DeclareFontShape{"s"}{ptsans}{m}{n}{<->'${k%%.ttf}'-"i"}{}"}'>>${i}ptsans.fd

и в новую строку перед последним done

echo '\endinput' >>${i}ptsans.fd

Это приведет к попутной генерации "скелетов" требуемых fd-файлов. Например, для t2a образуется файл

\ProvidesFile{t2aptsans.fd}
  [day-month-year v1.0 PT Sans at T2A encoding]
\DeclareFontFamily{T2A}{ptsans}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTC55F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTC75F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTN57F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTN77F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTS55F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTS56F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTS75F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTS76F-t2a}{}
\endinput

В котором, посмотрев на карты шрифтов, нужно вместо m и n прописать нужные насыщенность и начертание, например,

\DeclareFontShape{T2A}{ptsans}{sx}{n}{<->PTC55F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{bsx}{n}{<->PTC75F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{c}{n}{<->PTN57F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{bc}{n}{<->PTN77F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{n}{<->PTS55F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{m}{it}{<->PTS56F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{bx}{n}{<->PTS75F-t2a}{}
\DeclareFontShape{T2A}{ptsans}{bx}{it}{<->PTS76F-t2a}{}

Теперь можно, например писать {\fontfamily{ptsans}\selectfont Боюсь, \textbf{что вопрос уж очень широко \textit{сформулирован}...}}
или {\fontfamily{ptsans}\fontseries{sx}\selectfont Боюсь, что вопрос уж очень широко сформулирован...}}. Сюда можно подобавлять и подходящие подстановки, например,

\DeclareFontShape{T2A}{ptsans}{m}{sl}{<->ssub * ptsans/m/it}{}
\DeclareFontShape{T2A}{ptsans}{b}{it}{<->ssub * ptsans/bx/it}{}
\DeclareFontShape{T2A}{ptsans}{bx}{sl}{<->ssub * ptsans/bx/it}{}

Теперь, если шрифт прошёл проверку, то его осталось только отделить от текущего каталога --- все предшествующее не требовало тревожить могучего и ветвистого дерева ТеХ-системы. Делаем файл updmap.cfg из одной строчки

Map ptsans.map

запускаем

updmap --cnffile updmap.cfg

и раскидываем ttf, enc, tfm и fd по соответствующим веткам. После чего mktexlsr. Вместо однократной работы с updmap можно каждый раз использовать \pdfmapfile, но в этом случае будет необходимо ptsans.map тоже разместить в дереве ТеХ или всегда держать его в каталоге вместе с использующим его документом.

Попробую описать аналогичный процесс под Microsoft Windows. Лучший способ --- установить программку bash (awk и rm) и запускать приведённый сценарий после запуска bash. Но если с этим никак, то можно попробовать такой сценарий

for %%i in (ot1 t1 ts1 t2a t2b t2c t2d) do for %%k in (PTC55F PTC75F PTS75F ...) do call ttfencinst.bat %%k %%i n

Тут возникает проблема map-файла --- echo не печатает знак <. Можно вставить в ttfencinst.bat строку
echo %2-%1 @%2-%1.enc @%2.ttf >>ptsans.map
Это приведет к генерации нужного файла -- в нем только нужно @ заменить на <. А дальше все как и в Линуксе, только скелет fd-файла придётся делать вручную или с путанными трюками для ВАТ-файлов. Если с updmap не работает, то можно просто дописать содержимое ptsans.map в конец pdftex.map

Виртуальные шрифты не использовались, что позволяет использовать cmap и не позволяет подключить sc. Пока afmtoenc не поддерживает генерацию кодировок для sc, но возможно добавлю ее в следующей версии с поддержкой cmap отдельным пакетом. Виртуальный шрифт для поддержки sc, выдаваемый FontInst, принципиально не позволяет различать маленькие и большие буквы даже при генерации в уникод.

Спасибо, Николаю Леонову за добрые слова. :-)

Не могу ещё удержаться, чтобы не сказать, хотя и в оффтопик, несколько слов о пакетах типа deb. Конечно, пакеты -- это хорошо. Но на них нет единого формата, например, rpm не всегда удаётся свернуть в deb. И большинство программ, даже корневого характера, как правило, в новых версиях доступны только в исходниках, а в пакетах часто со значительным опозданием. И есть еще такой уже давно не новый термин как "ад зависимостей". Нет в мире совершенства, господа! :-(