On 2015-10-04 10:06 (+0200), Tavmjong Bah wrote:
> Going back further, the whole "write" chain is started in sp_file_open()
> when a document without a 'viewBox' attribute is given one (this is
> probably not necessary... we probably should not be adding 'viewBox'
> where one doesn't already exist... especially basing it off of the
> display unit).
See also the lengthy discussion in bug #1239682. That report is not closed yet (I moved the milestone to 0.92 for now, comment #30).
> Now, why would text in a symbol cause trouble? It is different from
> normal text in that symbols are not rendered directly. Styling may not
> be fully resolved at this point (just a guess). Needs further
> investigation.
Should we track remaining issues with styling in a separate, more specific report and close this one as fixed; or keep this one open for now (it might provide some context to whatever needs to be further investigated)?
On 2015-10-04 10:30 (+0200), Tavmjong Bah wrote:
> I went ahead and protected the string compare in
> SPStyle::getFontFeatureString() against a NULL value for
> font_feature_settings.value. This should probably be done anyway but the
> above questions about why this function is being called remain. "Fixed"
> in r14395.
"Fix" confirmed with r14395 on OS X 10.7.5 - both with the reduced test case, as well as with the original DXF import. Thanks a lot!
On 2015-10-04 10:06 (+0200), Tavmjong Bah wrote:
> Going back further, the whole "write" chain is started in sp_file_open()
> when a document without a 'viewBox' attribute is given one (this is
> probably not necessary... we probably should not be adding 'viewBox'
> where one doesn't already exist... especially basing it off of the
> display unit).
See also the lengthy discussion in bug #1239682. That report is not closed yet (I moved the milestone to 0.92 for now, comment #30).
> Now, why would text in a symbol cause trouble? It is different from
> normal text in that symbols are not rendered directly. Styling may not
> be fully resolved at this point (just a guess). Needs further
> investigation.
Should we track remaining issues with styling in a separate, more specific report and close this one as fixed; or keep this one open for now (it might provide some context to whatever needs to be further investigated)?
On 2015-10-04 10:30 (+0200), Tavmjong Bah wrote: :getFontFeature String( ) against a NULL value for settings. value. This should probably be done anyway but the
> I went ahead and protected the string compare in
> SPStyle:
> font_feature_
> above questions about why this function is being called remain. "Fixed"
> in r14395.
"Fix" confirmed with r14395 on OS X 10.7.5 - both with the reduced test case, as well as with the original DXF import. Thanks a lot!