I was trying to understand why fonts weren't working in an osga file. When I use osgarchive with fonts it apparently succeeds. Turns out it isn't, but it was failing silently (I sent PR #1242 to give better error messages).
The problem seems to be the way osgarchive was implemented. It's very convenient to rely on the ReaderWriter plugins, but IMO not the best strategy (for the osgarchive program specifically) for several reasons:
It limits osga to contain files that have both a reader and a writer implementation. In particular, the TTF ReaderWriter is unable to write an osgText::Font.
The process of parsing files only to serialize them again immediately afterward seems highly inefficient as a means of copying data into the archive.
osgarchive is limited to files supported by the plugins available to it on the specific machine where it runs. Consequently, if I have a custom format with its own plugin, but that plugin is not available on the machine running osgarchive (possibly due to OS incompatibility), I am unable to pack it from that particular machine.
These limitations also apply to extracting files from an archive. There is no point in parsing the thing just to copy it into a file. If a file has been successfully placed into the archive, it is reasonable to expect osgarchive to be capable of extracting it.
Would it make sense to extend the osgDB::Archive API with a couple of functions to write and read raw data, not just OSG objects? The use case would be tools such as osgarchive that don't care about what those files represent.
I was trying to understand why fonts weren't working in an
osgafile. When I useosgarchivewith fonts it apparently succeeds. Turns out it isn't, but it was failing silently (I sent PR #1242 to give better error messages).The problem seems to be the way osgarchive was implemented. It's very convenient to rely on the
ReaderWriterplugins, but IMO not the best strategy (for theosgarchiveprogram specifically) for several reasons:osgato contain files that have both a reader and a writer implementation. In particular, the TTFReaderWriteris unable to write anosgText::Font.osgarchive(possibly due to OS incompatibility), I am unable to pack it from that particular machine.These limitations also apply to extracting files from an archive. There is no point in parsing the thing just to copy it into a file. If a file has been successfully placed into the archive, it is reasonable to expect
osgarchiveto be capable of extracting it.Would it make sense to extend the
osgDB::ArchiveAPI with a couple of functions to write and read raw data, not just OSG objects? The use case would be tools such asosgarchivethat don't care about what those files represent.