On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> Is there a specific bug that forces us to require we have transitional > packages like this? RPM's Conflicts+Obsoletes logic is powerful enough > to allow us to avoid this. > I'm not aware of any BZ/Fedora wiki page that is requiring this. This solution was based solely on my best judgment. To clarify on this: The 'ghostscript-core' is a "main" subpackage in previous subpackage scheme. It basically contained almost everything from Ghostscript's compilation, and IIRC few of other packages were requiring this package directly in their specfiles... Other packages were not yet updated to requires correct subpackage from new subpackage layout. Therefore I decided to transform 'ghostscript-core' into auxiliary subpackage, since it was already there. This should have allowed new Ghostscript to be rolled out without breaking build process for them (hopefully completely, or at least it should at mitigate most of the problems). And the other packages can be then rebuild immediately once their requirements have been appropriately updated. :) Why are examples not shipped? For documentation, this seems to be > fine, especially since it's a separate subpackage anyway. > Upstream has decided to drop the examples/ completely from the next version of Ghostscript release (9.23). According to them those files are more useful for testing purposes rather than actual examples, and those files are poorly written PostScript files. They wouldn't help people who would like to learn how to write PostScript documents. That's why upstream does not want to ship those files anymore. Since I was doing changes to contents/layout of Ghostscript, I thought it was a good time to incorporate this change into the package already. > > * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use > > Ghostscript's default choice for rendering of CJK glyphs, which is Google > > Droid Sans Fallback font. In case this proves insufficient, the conf.d/ > > folder support will be re-established. > > > > ->> This change is still being discussed with Peng Wu and Akira Tagoh. So > > far, we have agreed to this change, but I will be ready to revert it in > case > > people depending on printing CJK-based texts will have any problems. In > case > > the Ghostscript's default functionality would prove to be sufficent and > work > > OK, then the 'ghostscript-chinese' package could be retired as a result. > > ->> For now, we are also waiting for rebase of 'google-droid-fonts' for > > Ghostscript to have the latest version of Droid Sans Fallback font and > thus > > the latest CJK glyphs coverage. > > > > I'm confused why we would drop support for conf.d directories. Unless > it's completely unavoidable, I don't see why we would do this. We > can't possibly know of everyone who might be using them, and generally > speaking, I'd like to see more software configurable this way, not > less. > The folder /usr/share/ghostscript/conf.d/ actually comes from the package 'ghostscript-chinese'. Ghostscript itself was just configured to check that folder for configuration before, if there was any. The folder itself contained mappings for specific locales into specific CJK-based fonts. It was used only after 'ghostscript-chinese' was installed. This solution was introduced into Ghostscript more than a decade ago, and it is based on this project: https://www.freedesktop.org/wiki/Software/ CJKUnifonts/ If you look at the project, you will that it is basically dead, and the 'ghostscript-chinese' package itself received last update in 2012. The main purpose of using 'ghostscript-chinese' is to introduce a workaround for displaying/printing of CJK-based documents which do not have the correct font embedded (for displaying the glyphs inside the document text). When document wouldn't have correct CJK font(s) embedded inside it, then Ghostscript would the closest substitution(s), so the document can be at least displayed/printed in a readable/legible way. However, the substitution will never be perfect, and will always be best-effort workaround. The above described situation was valid several years ago. Nowadays upstream has its own solution (i.e. workaround) on doing so, which is based only on one (different) font - Google Droid Sans Fallback. I'm still discussing this change with Peng Wu (maintainer of 'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer) off-the-list, but for now we have agreed to try use the default upstream's solution for this scenario. If it works well, this should mean less maintenance work for Peng ('ghostscript-chinese' could be dropped), and we wouldn't have a downstream solution that could potentially cause additional issues in the future. Also, the downstream solutions were really not popular with upstream before (IMHO they didn't like Fedora at all because of it), and I was working with them for last half and a year to improve our relationship with them from Fedora side. :) I hope I didn't forget to mention something important... :D If something is unclear, lay it on me! ;)
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
