You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I was trying to understand why fonts weren't working in an
osga
file. When I useosgarchive
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 theosgarchive
program specifically) for several reasons:osga
to contain files that have both a reader and a writer implementation. In particular, the TTFReaderWriter
is 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
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 asosgarchive
that don't care about what those files represent.The text was updated successfully, but these errors were encountered: