Системный шрифт PSP

[lis5131]

Ковырнул тут на досуге игру. Задался интересным вопросом.
Суть такая. Игра использует системный шрифт ltn3.pgf и ltn5.pgf (точнее две разных игры.)
Есть ли возможность заменить этот шрифт через плагин. (не трогая flash0)?

[lupus]

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

[ErikPshat]

Сообщение от lupus Можно попробовать такой костыль: использовать вместо ascii пробела что-то вроде • предварительно исправив этот символ в ttf.

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

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

[riku.kh3]

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

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

riku.kh3 добавил 09.05.2014 в 14:04

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

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

[ErikPshat]

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

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



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

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

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

[riku.kh3]

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

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

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

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



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

[ErikPshat]

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

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

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

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

[riku.kh3]

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

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

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

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

[ErikPshat]

Сообщение от riku.kh3 просто занимает 0 пикселей

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

[ErikPshat]

Сообщение от riku.kh3 (с　shiftjis　пробелом　он　работает) и в сохранениях будут крокозябры. То есть идеальным решением все-таки было бы уменьшить существующий shiftjis пробел вдвое.

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

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

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

[riku.kh3]

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

[ErikPshat]

Сообщение от riku.kh3 зменить $20 пробел на shiftjis пробел ($8140)

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

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

windows-1251.png Shift-JIS.png

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

Windows-1251

Hex_windows-1251.png

Shift-JIS

Hex_Shift-JIS.png

---

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

[riku.kh3]

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

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

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

[ErikPshat]

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

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

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

---

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

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

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

[ErikPshat]

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

[riku.kh3]

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

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

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

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

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

゜

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

[ErikPshat]

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.

[ErikPshat]

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

Он　указал　на　Кёске,　который　спал　как　будто　пьяный. ругом,　было　то,　что　Кёске　вернулся.

текст.png

хекс.png

[riku.kh3]

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

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

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

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

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

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

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

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

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

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

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

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

riku.kh3 добавил 13.05.2014 в 16:46

Сообщение от ErikPshat Выложу сюда скриншоты, чтобы мне было легче ориентироваться по кодам... Почему у тебя ошибки в переводе? )) Он　указал　на　Кёске,　который　спал　как　будто　пьяный. ругом,　было　то,　что　Кёске　вернулся. Вложение 10033 Вложение 10034

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

[ErikPshat]

Сообщение от riku.kh3 Каким образом игра вообще может знать о существовании русской 1251 не представляю.

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

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

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

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

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

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

[riku.kh3]

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