On Wed, 2010-03-31 at 00:28 +0300, LightningIsMyName wrote:
> I took a look on the commit logs, and I haven't seen any update to the
> text tool which should affect exporting it's markup, in the last 3
That is because I didn't have much time, and is no indication that
the text tool is finished. There are in fact a lot of things left,
also with the internal representation.
> So now it's time at least discuss which kind of export do we want for
> the markup:
> - Do we want an export which exports pango's markup directly? Although
> this should be the easiest technique, it might be a burden if for some
> reason we change to a different text-rendering library in the future
> (This shouldn't happen, right? If so, this is probably OK)
> - Do we want an export which exports to some HTML and CSS combination?
> Right now pango does something very close to this, however it includes
> some attributes which should be inside a style attribute in valid CSS.
> This is less "pango-dependant" and it is probably a better idea to use
> valid HTML/CSS if we want to allow other uses of the exported text
> (instead of just usage with Pango as in the PDF plugin).
> Note however that in this case, there are some elements that it's
> unclear how to export since Pango's markup supports several attributes
> (such as "fallback") which HTML and CSS don't support.
> - Other export format?
> I obviously tend to like the first option more (Pango-style markup)
> since it requires no writing of convertors for the markup from our
> current internal represenation, and as far as I know Pango is here to
> If this option is indeed the way to go, I have a fixed code ready that
> I can create the patch from.
It's most likely going to be pango markup. However, since GIMP will
only understand pango markup it produced itself, let's call it
GIMP markup right away. But as said, the exact set of features
is undecided, and there is currently even a bad hack involved
> I'll continue working on the PDF plugin as soon as we are done with this =)
Great :) Let's discuss the details in #gimp some time next week.
> On Thu, Mar 4, 2010 at 12:49 AM, Sven Neumann <s...@gimp.org> wrote:
> > On Wed, 2010-03-03 at 22:35 +0200, LightningIsMyName wrote:
> > > On Wed, Mar 3, 2010 at 9:17 PM, Sven Neumann <s...@gimp.org> wrote:
> > > >> Is there any way in which I can acces the style of the text?=
> > > >
> > > > Such a way will have to be added of course. We usually add the core
> > > > functionality first, then expose it to plug-ins. It's easier this way
> > > > around.
> > > >
> > > > It should be unproblematic to add a procedure that exposes the new
> > > > "markup" property of the text object.
> > >
> > > OK, I found the markup property you are mentioned - It shouldn't be
> > > too problomatic to extract it (I'll probably be able to add the patch
> > > myself). However, before I continue working on the plugin, are there
> > > any other upcoming changes in the text-engine which will affect the
> > > plugin?
> > Almost certainly. The feature is brand-new, you should give it some time
> > to settle.
> > > And another thing - with al the late discussions about color profiles,
> > > It made me wonder: exporting a PDF via cairo does not support color
> > > profiles. Do we need to warn the user if the image has some specific
> > > color profile, that the PDF will be exported in the default RGB
> > > profile? Or do we continue to stick to the fact that this is an extra
> > > feature (andnot a complete feature with CMYK and other PDF related
> > > features) in gimp and therfor we don't need to warn about such errors
> > > that don't bother most of the users?
> > Almost all our file plug-ins are missing color profile support and we
> > don't warn users in any of them.
> > Sven
> Gimp-developer mailing list
Gimp-developer mailing list