Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

osgarchive can only pack file formats for which there is a writer #1243

Open
rubenlg opened this issue Jul 7, 2023 · 0 comments
Open

osgarchive can only pack file formats for which there is a writer #1243

rubenlg opened this issue Jul 7, 2023 · 0 comments

Comments

@rubenlg
Copy link

rubenlg commented Jul 7, 2023

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:

  1. 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.
  2. The process of parsing files only to serialize them again immediately afterward seems highly inefficient as a means of copying data into the archive.
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant