forums.ps2dev.org

[hubevolution]

anyone has a clue about the pgf format used for psp fonts ?

actually the name encoded into 'ltn0.pgf' is 'FTT-NewRodin Pro Latin' and seems to be a commercial true type font you can buy from fontworks :

http://www.fontworks.com/typography/fontinfo/newrodin.html

I would say that the FTT initial name reminds me of TTF -> truetype file format that is pgf is a sort of custom TTF and $ony should have a sort of encoder to produce pgf from ttf files.

PGF cannot be much different from TTF since the complessity of the file format so would be a good idea to study the OpenType format :

http://www.microsoft.com/OpenType/OTSpec/

just to see some similarity in the header part ...

do you think this could be or am I completely wrong LOL ?

anyone interested going deeper into pgf format ?

thx

[R2k]

Skylark and Freeplay has decoded the PGF but only in a very basic mode see this page http://mirror.toc2rta.com/index.php/PspFont

and TeamOverload has customized the psp fonts as you can see in his blog http://teamoverload.blogspot.com/ or to the QJ.net thread http://forums.qj.net/showthread.php?p=506582&page=19

Note: the follow is off-topic but related with this
this is a tutorial (yet not tested) to customize your fonts in the psp http://pspupdates.qj.net/Customize-Your-PSP-Font-Today-/pg/49/aid/11450

[ufoz]

On a related note, is it possible to open these files from the firmware for reading in user mode? Because it would save a lot of space (and effort) to use the built-in Japanese font than to bundle my own.

Edit: to answer my own question, yeah, it's possible to read the files from flash0, at least in 1.5 - can't be bothered with gta right now. So I think I'll try to get this working.

[R2k]

i think that is possible, but at the moment i don't know if exists a function that do that. You can do a function to transfer PGF from flash0:/ to ms0:/ and later decode and use it like a normal bitmap only displaying the part of the bitmap that correspond to the character that you want to show.

Edit: if you code such function post or release it in open open source. Could be a great piece of code. hehehehe

Edit2: in GTA you have read-noly access to flash0:/

[dot_blank]

pgf is specifically Progressive Graphics File
PGF is a new image file format for natural
and aerial images, which offers both lossless
and lossy compression. i believe their is a Tex app
that can handle these ...search sourceforge and ye
shall find

here is more info http://www.xeraina.ch/pgf/
_________________
10011011 00101010 11010111 10001001 10111010

[R2k]

Try to verify that the fonts can be loaded by Tex PGF viewer ...

Edit: Freeplay and Skylark has released a TTF to PGF converter in their wiki
_________________
PSP FW v2.6 owner

[ufoz]

Completely different PGF, there.

Anyway, the files can be read out of flash0 by simple fread or whatever functions, so maybe a libpspfont or something would be in order. I'll see if I can get something working. (or possibly Skylark and the others are working on something like this already...)

[dot_blank]

there still is libfont that needs some reversal
maybe somebody should get on that ;)

R2k: well that certainly seems like a handy app
i wonder the performance benefits (if any) compared
with Truetype fonts
_________________
10011011 00101010 11010111 10001001 10111010

[fanispap]

Any news from the front????

Is there any pgf to ttf converter? Is it possible?

[KickinAezz]

http://hitmen.c02.at/files/yapspd/psp_doc/chap26.html#sec26.9
Shud be enuf for now ;)

[FreePlay]

[fanispap]

[BenHur]

I'm not aware of a program capable of handling pgf files. The file format is known good enough to generate pgf files (thanks to Skylark and Freeplay), but not to read generic pgf files. I did some more research (sorry for the long post, skip it if you're not interested in the pgf file format):

****pgf file format start****

pgf files consist of the following elements:
1. header
2. table 1 (signed 32bit numbers, length unknown)
3. table 2 (16bit numbers, length unknown)
4. table 3 (look-up table, bitsize and length specified in header)
5. table 4 (pointer table, bitsize and length specified in header)
6. font data (number of chars and shadows specified in header)

header:
0x0004: "PGF0" pgf file ID (4 bytes)
0x0010: # of elements in table 3 (32bit)
0x0014: # of elements in table 4 = # of chars in pgf file (32bit)
0x0018: # of bits per element in table 3 (32bit)
0x001C: # of bits per element in table 4 (32bit)
0x0035: font family name (64 bytes)
0x0075: font type: regular/bold/italic (64 bytes)
0x016C: # of shadows in pgf file (32bit)
0x0178: x-scalefactor for shadows: 32=2.0 / 64=1.0 (32bit)
0x017C: y-scalefactor for shadows: 32=2.0 / 64=1.0 (32bit)

table 1:
starts maybe around 0x0180, i know little about it at this time (including e.g. its length!)

table 2:
may contain 16bit representations of the chars stored in the font data
(but is too short to contain all chars of e.g. jpn0.pgf). I don't know the start position or length of this table.

table 3:
Is a look-up table of some sort as it contains values between 0 and # of chars or the value -1 (for the cases where the requested char is not in the pgf file?). This table always (in all pgf files available) starts with the values 0,1,2,3,4,5 - this is a (cumbersome) way to locate table 3. It's length is # of bits times # of elements rounded up to the next multiple of 4 bytes.

table 4:
Is the main pointer table, which stores the file offsets in bytes of all chars (relative to the beginning of the font data). It's length is # of bits times # of elements rounded up to the next multiple of 4 bytes.

font data:
Each char (pointed to by table 4) has a char metric record with an extension, followed by the RLE compressed char-bitmap. This is optionally followed by a shadow metric record without an extension and a shadow bitmap.

The basic metrics record (6 bytes) contains the following fields:
- 14-bit length of the char metric record and char bitmap
- 7-bit width
- 7-bit height
- 7-bit signed horizontal adjustment
- 7-bit signed ascender
- 2-bit transposition (1 - horizontal rows, 2 - vertical rows)
- 4-bit metric type: 0 - shadow metric (no extension), 8 - char metric (27 byte extension), 9/10/12 - char metric (20 bytes extension), 13/14 - char metric (13 bytes extension), 15 - char metric (6 bytes extension)

The extension (char metric record) contains the following fields:
- 6-bit unknown data
- 9-bit shadow-indexnumber (if same as char-indexnumber: there is a shadow metric record/bitmap combination after the char-bitmap)
- variable amount of bits (depending on extension length) unknown data
- last 6-bit of extension record: horizontal advance

The RLE compressed bitmap is well explained in
http://hitmen.c02.at/files/yapspd/psp_doc/chap26.html#sec26.9

****pgf file format end****

Using the above method i can render latin (ltn*.pgf) and japanese (jpn0.pgf) fonts of any firmware version. kr0.pgf and arib.pgf are only partially rendered correctly and are not yet understood well enough.

I hope I'm not re-inventing the wheel...

Question: does a library or fw function exist to render text and shadow using the firmware pgf fonts? Would that be something worth developing? (There is freetype,... but this method would save resources and retain the psp-look.)

Greetings, BenHur

[FreePlay]