Я, когда над переводом ff3 работали, с этими шрифтами намаялся. Правка ttf по ширине ничего не даст. Ttf2pgf штука не идеальная, но это лучшая софтина из тех, что я нашёл. В самом pgf хранится битмап символов и таблица ширин, пожато это всё rle алгоритмом. К сожалению ни одной программы, которая бы умела напрямую править pgf, мне найти не удалось.
Можно попробовать такой костыль: использовать вместо ascii пробела что-то вроде • предварительно исправив этот символ в ttf.

Да, согласен. В переводе можно вместо пробела использовать любой международный символ, например знаки препинания беруться из общего набора международных шрифтов, такие как !?";:*#() и т.п.. Можно взять любой узкий малоиспользуемый знак и через редактор шрифтов TTF зачистить этот символ, либо перекопировать на его место пробел. Затем сконвертировать в PGF.

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

lupus, в комплекте с pfgtool помимо основной ttf_pgf.exe, есть еще dump_pgf.exe. Она умеет полную информацию по каждому символу в pgf выводить, в том числе и информацию о длине/ширине. Знающий человек посмотрев исходники dump_pgf, по идее, сможет понять где все это хранится и как изменить.

ErikPshat, как уже говорил: международные символы (ascii) править в TTF не поможет. ascii символы после конвертирования в pgf на экране занимают ровно столько места, сколько сами глифы. Если стереть все глифы, то символ абсолютно 0 пикселей интервала будет занимать и просто пропадет.

riku.kh3 добавил 09.05.2014 в 14:04
В этом плане тут все еще даже хуже, игра понимает скриптовые комманды в тексте и различные сочетания ascii буковок могут стать триггером комманд.

Ну вот возьмём shift-jis пробелы:

http://s020.radikal.ru/i720/1405/da/b2e49c67773a.png

Возьмём для примера кавычки " с которых начинается предложение.
Как видно, после кавычек пробела нет и они занимают маленькое расстояние.
Если мы эти кавычки затрём, чтобы на экране вместо них отображалось пустое место, то получится вполне компактный пробел.

То есть, в переводе нужно писать в кодировке shift-jis, но вместо пробелов ставить кавычки. Либо, если уже перевод осуществлён, через поиск замену можно тупо массово заменить пробелы на кавычки, хоть в тексте хоть в хексе.
Тогда, как видно на скрине - расстояние между буквами нас устраивает и так же будет устраивать пробел (пустые кавычки). А PSP будет думать, что мы ставим кавычки и не будет добавлять 2-ой пробел.

Другое вопрос в том, сможем ли мы, исправив TTF, сконвертировать шрифт в PGF, чтобы он потом мог отображать писанину, сохранённую в shift-jis ?

Пробела как раз таки и не получается, символ и занимаемое им место пропадут. И даже если получится это реализовать, бонусам перестанет работать перенос слов (с　shiftjis　пробелом　он　работает) и в сохранениях будут крокозябры. То есть идеальным решением все-таки было бы уменьшить существующий shiftjis пробел вдвое.

С этим проблем нет:

http://s52.radikal.ru/i137/1405/8d/ab57e5aab45f.png

(скрин не самый удачный, т.к. пробелы на нем по прежнему проблемные - $20)

Не понимаю, как может пропасть занимаемое символом место. Система будет всё равно думать, что символ на том месте есть и никуда он не пропадёт. Ведь код символа останется тем же, но не такой код пробела 0x20, а уже тот самый родной код символа, кавычек например.

И с чего перестанет работать перенос? Неужели для переноса ты используешь символ пробела?

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

При конвертации из TTF в PGF это, по видимому, происходит. По сути, он никуда не пропадает, просто занимает 0 пикселей и визуально его не видно.

Я не о ручном переносе слов говорю (это было бы кошмаром, учитывая объемы текста), а об автоматической, которая в игре реализована.

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

Такс, по-моему ты мне вводишь в заблуждение мои мозги :)
О каком таком пробеле shiftjis идёт речь? Ты мне уже всю тему про эти пробелы твердишь.

Вот сейчас проверил код пробела в обычной windows-1251 и в shiftjis - символ пробела один и тот же 0x20.
Так что тут пробел абсолютно не при чём. Крашится игра при сохранении не из-за пробела, а из-за управляющих символов, попавших в кириллический диапазон win-1251.

Думаю можно сохранять в другой кодировке, например UTF-8 или UTF-16LE(BE), либо в чём-нибудь другом, где возможно не используются служебные символы от игры.

ErikPshat, да там просто все замороченне некуда - $20 пробелы не в 100% случаев вызывают крэши при сохранении. Но, опять же, во многих случаях если во фразе, на которой происходит крэш, зменить $20 пробел на shiftjis пробел ($8140), то сейв происходит нормально.

Опять же говорю, что Shift-JIS пробел всегда имеет код 0x20.

Вот для примера я сохранил один и тот же текст "Привет Кёске, как дела?" в разных кодировках:
(название текстовика видно в заголовках программ, а кодировка текстовика видна в нижней части программы)


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

---

Ну может быть PSP действительно берёт не тот код пробела, а по своему, из другой области 0x8140.
Но непонятно тогда, ведь когда ты сохраняешь текст в Shift-JIS на компьютере, то код пробела должен быть 0x20.

ErikPshat, в японском языке пробелы по-сути вообще не нужны, и редко когда используются. Как и все остальные ascii символы вроде: .,"'()[] ... т.к. там есть свои: 。、゛’「」『』…

Но не в этом суть. То, что я называю shiftjis пробелом - это стандартный, как и все остальные shiftjis символы, двухбайтовый пробел. Вдаваться в смысл как конвертеры кодировок работают не стоит, достаточно просто знать, что ascii пробел (однобайтовый, 0x20), как и остальные ascii символы (.,"'()[] и т.п.) он переносит как есть.. т.к. shiftjis кодировка включает себя саму ascii (хоть она на практике практически и не используется) и по мнению конвертера и фактически оно всегда будет отображаться как надо.

И еще уточню по поводу русских буковок в shiftjis: по стандарту, они часть японской кодировки (как греческие буквы и т.п.), и восприниматься, по сути, должны как и остальные иероглифы... но похоже, что конкретно с этой игрой все гораздо сложнее.. хоть и сам русский текст в игре в чистом shiftjis'е, судя по всему, происходит вмешательство libfont (или другого?) psp модуля, и конвертирование текста в юникод (насколько я понял, pgf формат шрифтов в юникоде) и это вызывает рэндомные крэши вообще независимо от пробелов. :scratch_one-s_head:

riku.kh3, ну вот ты сохрани любой текст в любом текстовом редакторе в кодировке shift-jis.
Потом проверь в хексе, какие коды в этом shift-jis сохранились. Ты сам убедишься, что пробел там 0x20.

Собственно сдампил из памяти PSP один диалог с твоего перевода. Там действительно вместо обычного пробела подставляется "длинный пробел" 2 байта = 0x8140.
Эти пробелы так же используются в программировании, для отступов исходного кода. "Длинные пробелы" так же бывают 4-байтными и 8-байтными. Ну ты сам наверное встречался с такими, когда в исходниках хочешь удалить или выделить один пробел, а на самом деле удаляется или выделяется длинная полоса.

Мне кажется, что в конвертере допущена ошибка, когда он сам вместо пробела вставляет служебный символ.

---

Короче, вот кусок дампа памяти: Вложение 10032
Там ELF-код лишний почистил, оставил только выводимый текст и инфу по шрифту (FTT-NewRodin Pro DB), которые оказались в дампе.
Причём в памяти коды символов букв не совпадают с кодом в прилагаемом тобой шрифте (HGRSGU002.TTF). То есть, в твоём TTF-шрифте идёт сдвиг кодов.

И да, в дампе памяти используется служебный "длинный пробел" 0x8140.
Я думаю, что его подставляет конвертер изначально, а не PSP его так подменяет.

Кстати, есть идея сдампить оригинальный японский диалог и подсмотреть, какой символ пробела там подставляется.

Короче, текст нужно писать, чтобы не было багов, в Shift-JIS кодировке.
Но пробел должен быть стандартный 0x20, как и положено в Sift-JIS, а не 0x8140.

ErikPshat, давай проссуммируем что мы имеем:

1) Никто нам не запрещает использовать стандартный ascii пробел (0x20) и он прекрасно отображается в тексте, но это одна из причин, по которой игра рэндомно крэшится на сейве.

2) Тулза для вставки текста в SCRIPT.PAK дает использовать 0x20 пробел, но я специально их все заменил на $8140 пробел чтобы выявить закономерность крэшей.

3) Использование русских буковок в shiftjis (8440-8460, 8470-8491) еще одна из причин рэндомных крэшей (что-то связано с юникодом pgf шрифта?)

4) Двухбайтовые shiftjis символы, хоть и выглядят все одинаковой длины, не моноширинные. Доказательство тому символ $814B:
5) Изменить ширину shiftjis символов играясь с TTF не представляется возможным, после конвертирования в PGF ширина у каждого символа всё та же как и была.

1) Ты говорил, что с Shift-JIS кодировкой всё в порядке. А вот с однобайтовой 1251 вкупе с пробелом 0х20 - происходят креши. Поэтому я так и понял, что в кириллице именно 1251 используются служебные символы.

2) По видимому ты сам значит выставил такой длинный пробел, вместо короткого )))

3) Тогда это причина перейти на другую кодировку, например UTF-8, там символы в диапазоне 0401 - 0451. И возможно игра не использует из этого диапазона служебные коды.

4) Ну и русский 2-байтный шрифт так же в Shift-JIS выводится, как однобайтный, вернее нормальной ширины. Так что не в этом проблема.
2 байта на символ - это всего-лишь порядковый номер символа в таблице шрифтов и это совсем не значит, что символ выводится 2-мя байтами.

5) Я уже посмотрел таблицу шрифтов - там даже нету в таблице этого кода пробела 0х8140. Поэтому этот код пробела берётся не из таблицы шрифтов TTF или PGF, а оно уже заложено в либах.

---

И поэтому я предлагаю:

1. Либо сменить кодировку.
   
   
2. Либо вместо пробела использовать другой неиспользуемый символ и заменить его стандартным пробелом, т.е. вместо того символа скопировать/вставить пробел. Затем в конвертере пакетно заменить код 0х20 на код того символа, точно так же, как ты заменил на 0х8140.

Выложу сюда скриншоты, чтобы мне было легче ориентироваться по кодам...
Почему у тебя ошибки в переводе? ))

ShiftJIS кодировка - это единственная в которой я разбираюсь и знаю как устроена. Каким образом игра вообще может знать о существовании русской 1251 не представляю. :scratch_one-s_head:

Да, специально, крэшей стало намного меньше, но они по прежнему есть.

Опять же, понятия не имею как это все устроить, и как модуль шрифтов это все обрабатывает.

Пардон, я думал 1251 кодировка тоже однобайтная, с ней не приходилось просто никогда работать. Никогда не видел чтобы с shiftjis кодировкой такое срабатывало.

TTF, насколько я понимаю, в юникоде и там у него код другой. PGF вроде как тоже в юникоде. :scratch_one-s_head:
Ссылку я уже давал, тут коды всех символов в shiftjis:
http://www.seiai.ed.jp/sys/text/java...jis_table.html
Сначала идет "половинчатая", однобайтная область, затем "полная", основная, двухбайтная.

Да, я уже это делал, частично проблему крэшей это решает.. Но по причине №3 не полностью.

riku.kh3 добавил 13.05.2014 в 16:46
Это не ошибка, это куски разных фраз слепленные в одну. Тулзу, которую я давал, через AppLocale если запустить из японской среды, то можно нормально каждую фразу на русском смотреть и редактировать.

Эмм, по-моему ты совсем в этом ничего не понимаешь :D
Или, скорее всего, ты себе сам всё усложняешь тогда, когда всё на самом деле очень просто.

Кодировка - это всего-лишь набор символов и всё! Просто в каждой кодировке все буквы пронумерованы по разному. Взять чисто однобайтную кодировку, то там количество кодов не превышает 0xFF, что получается, если перевести в десятиметричную систему 256 символов.
А как же добавить 257-ой символ?
Вооот! Тут-то 0xFG уже не проканает, потому что в 16-ричной системе максимальное число F и уже нету G ))) ну ты сам знаешь.
Поэтому, чтобы поместить в таблицу 257-ой символ, приходится считать дальше по правилам: 256 = 0xFF, 257 = 0x0100, а 65535 = 0xFFFF.
Вот тебе и всё правило кодировок 1-байтных или 2-байтных.

Поэтому секрет 2-байтных кодировок в том, что в ней присутствует и 1-байтная кодировка :D потому что элементарно подсчёт символов в любой кодировке начинается с нуля, а не с центра вселенной.
Ты же яйца в корзине, если их там 100 штук, начинаешь считать всё равно с 1 единицы, а не с 50-ти )))

Кодировки между собой отличаются только количеством символов и соответственно их порядковым номером в 16-ричной системе.
Если ты хочешь писать в UTF-8, то и символы русского алфавита нужно подсунуть в её диапазон в шрифте.
Кстати, в Shift-JIS я вижу, что русские символы как раз дублируются в диапазоне UTF-8 (0401 - 0451). Таким образом, можно тупо сохранять текст в UTF-8 и шрифт Shift-JIS будет его отображать.

ErikPshat, по прежнему не объясняет почему игра должна понимать UTF-8. Под shiftjis выделена четкая область и границы начиная с $8140 (ну + ascii еще 00-FF), на все что ниже ей просто параллельно и она не будет это отображать.