I need to edit portions of some bitmap font files, and save the result to disk, but seem to go nowhere.
I started by dragging the file into the project, thinking I would simply access it a string. Unfortunately, as it starts by chr(0), it seems Xojo takes it as empty.
Then I proceeded to use Binarystream to load it from disk, same result.
After trying to load the data into a memoryBlock using Xojo.io.BinaryStream unsuccessfully, I am out of ideas.
I just tried this :
[code] dim f as folderitem = app.executablefile.parent.parent.child(“Resources”).child(“antic.bmap”)
msgbox str(f.exists)+" "+str(f.Length)[/code]
The file indeed exists, and in the finder is 2K long, but I get zero length.
For all intents and purposes, Xojo seems completely unable to deal with a file that starts with chr(0).
I had to zip it, because when I uploaded it, it arrived on the server as a zero bytes file. Yet, the archive recreates a 2K file on disk.
It is a suitcase file coming from Classic OS 9.x.
I just compared with other bmap files, they all have the same problem.
So it was not chr(0), it was suitcase. One more special mystery about such files under Mac OS X we do not know about.
EDIT : Ouch, ouch, ouch. It is even more vicious than I thought.
The compressed file is a zero length file. But opening the same archive on PC, I found in the _MACOSX folder a hiden file called ._antic.bmap which is the actual 2K file. I renamed it and am going to see how it fares back on PC.
It seems Apple is going to great length to prevent anybody to fuss with suitcase files…
I don’t know how big the file should be, but when i unzip it on a pc the file shows up as a zero byte file, just as you say. But unzipping the file also shows the same filename preceded with an underscore in the __MACOSX folder within in the zip file and that file shows a size of 2046 bytes while it starts with chr(0).
[quote=251476:@jean-paul devulder]f.length is zero i confirm
i try open file with hexa editor, i can’t[/quote]
It is a mess. The file I saved on PC once repatriated on Mac shows a header that was not apparent in the original file. That warrants much more investigations. It looks as if Mac OS X uses some wizardry with suitcases I will have to unravel before I can hope do anything with that.
[quote=251479:@Eli Ott]If I recall correctly, bmap is holding the screen version of the actual font file. So without the actual font file a bmap file will not be useful.
But this is 90s stuff and I’m therefore not totally sure.[/quote]
Indeed, the Classic era bitmap does not work on Mac OS X. BUT if you click on the bitmap, it shows the associated PostScript font.
What I am after is a way to activate Classic PostScript fonts with Fonts Manager. I have a customer who has kept some 18,000 PostScript fonts WITHOUT the associated bitmap (users are sometimes so strange, the Universe keeps making more), so I am trying to come up with a way to recreate a mocked up bitmap font which sole purpose is to activate the PostScript file under Mac OS X.
I was able to do so with a hex editor, now I need to do the same with Xojo…
Some “interesting” reverse engineering and historic documents digging in perspective…
OK. Further along seeking access to the resource fork.
I can display the content of the resource fork with
cat antic.bmap/..namedfork/rsrc
Now if only I could figure how to edit it, that would be great. Of course, Xojo GetFolderItem chokes badly on such a path. It is getting late here. With some luck I will find the way tomorrow.
I seem to recall that MBS has a ResourceForkStream class or is it Einhugur? That allows you to open the resource fork of a file as a binary stream.
However I really don’t have much hope for the future of files with Resource Forks, I see sometimes code signing can choke if a file has a resource fork.
If you can use the terminal command CAT to extract data from the resource fork, I suspect there’s a way to turn it into a bonefide seperate file, then edit what you want from it.
Maybe there’s another way to get the Postscript data without needing a suitcase file?
For whatever reason, there is no way to activate a Classic PostScript font without. However, what I am doing at the moment does not require the resource fork to be stored in the bundle. I actually just succeeded using an uncompressed tar file which I can modify before putting it on disk and extract.
[quote=251519:@Christian Schmitz]MBS has a resource fork class. We wrote it when Xojo lost his class.
We also have a module for extended attributes.[/quote]
Superb. I found ResourceForkMBS. That may be particularly precious as I want to study the possibility to convert PFA PC files to a format I can activate on Mac.
I am getting nowhere. It is possible to open a resource with ResourceForkMBS.Open, or to create one with ResourceForkMBS.Create, but I see nowhere any way to apply the changes to the file it came from.
[quote=251507:@Sam Rowlands]I seem to recall that MBS has a ResourceForkStream class or is it Einhugur? That allows you to open the resource fork of a file as a binary stream.
However I really don’t have much hope for the future of files with Resource Forks, I see sometimes code signing can choke if a file has a resource fork.
If you can use the terminal command CAT to extract data from the resource fork, I suspect there’s a way to turn it into a bonefide seperate file, then edit what you want from it.
Maybe there’s another way to get the Postscript data without needing a suitcase file?[/quote]
