[trunk] Two small details again about SVG embedding

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[trunk] Two small details again about SVG embedding

Miwarre
Hi,

Before filing issues for these two details, I prefer to know more about them.
____________________________________________

1) SVG drawing:

In function SvgImage::draw() (file image.cpp, line 231), the cache buffer is filled with white background (white is the default parameter for the fill() function):

buffer.fill();

I think this is not entirely correct: SVG images (as well as other types of images) can have a transparent background and this transparency may be necessary to combine drawing elements into more complex drawings; by filling the background with a solid colour, any image become non-transparent.

If setting the buffer contents to a known state is required, I think the buffer should be filled with the 'transparent' pseudo-colour:

buffer.fill(Qt::transparent);

If setting this is not necessary, the line can be entirely removed.
________________________________________________

2) Hard-coded image size in addImage() method.

(This applies to ALL types of image, not just SVG.)

In the MuseScore::addImage() function (file file.cpp, line 1700 and foll.), which implements the "Add | Picture" contextual menu command for a frame, the image size is set to a fixed 200x200 size (I think 200 raster units); see line 1729:

s->setSize(QSizeF(200, 200));

I think this line is a left-over of some test / experiment and should be deleted, allowing the image to keep its own size (the size is actually set in the setPath() function called in line 1728).
___________________________________________

I made both changes in my local copy and I did not notice any negative side effect. Comments?

Thanks,

M.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [trunk] Two small details again about SVG embedding

David Bolton-2
I'm supportive of these changes.

DB

On 1/28/2012 12:16 PM, Miwarre wrote:

> Hi,
>
> Before filing issues for these two details, I prefer to know more about
> them.
> ____________________________________________
>
> 1) SVG drawing:
>
> In function SvgImage::draw() (file image.cpp, line 231), the cache buffer is
> filled with white background (white is the default parameter for the fill()
> function):
>
> buffer.fill();
>
> I think this is not entirely correct: SVG images (as well as other types of
> images) can have a transparent background and this transparency may be
> necessary to combine drawing elements into more complex drawings; by filling
> the background with a solid colour, any image become non-transparent.
>
> If setting the buffer contents to a known state is required, I think the
> buffer should be filled with the 'transparent' pseudo-colour:
>
> buffer.fill(Qt::transparent);
>
> If setting this is not necessary, the line can be entirely removed.
> ________________________________________________
>
> 2) Hard-coded image size in addImage() method.
>
> (This applies to ALL types of image, not just SVG.)
>
> In the MuseScore::addImage() function (file file.cpp, line 1700 and foll.),
> which implements the "Add | Picture" contextual menu command for a frame,
> the image size is set to a fixed 200x200 size (I think 200 raster units);
> see line 1729:
>
> s->setSize(QSizeF(200, 200));
>
> I think this line is a left-over of some test / experiment and should be
> deleted, allowing the image to keep its own size (the size is actually set
> in the setPath() function called in line 1728).
> ___________________________________________
>
> I made both changes in my local copy and I did not notice any negative side
> effect. Comments?
>
> Thanks,
>
> M.
>


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [trunk] Two small details again about SVG embedding

lasconic
All good for me too. I don't know if buffer.fill() is mandatory but a
known state is better than unknown.

Could you open a bug in the issue tracker and reference it in your
commit? or attach a patch to the issue if you want me to commit it for
you?

Lasconic

>
> On 1/28/2012 12:16 PM, Miwarre wrote:
>> Hi,
>>
>> Before filing issues for these two details, I prefer to know more about
>> them.
>> ____________________________________________
>>
>> 1) SVG drawing:
>>
>> In function SvgImage::draw() (file image.cpp, line 231), the cache buffer is
>> filled with white background (white is the default parameter for the fill()
>> function):
>>
>> buffer.fill();
>>
>> I think this is not entirely correct: SVG images (as well as other types of
>> images) can have a transparent background and this transparency may be
>> necessary to combine drawing elements into more complex drawings; by filling
>> the background with a solid colour, any image become non-transparent.
>>
>> If setting the buffer contents to a known state is required, I think the
>> buffer should be filled with the 'transparent' pseudo-colour:
>>
>> buffer.fill(Qt::transparent);
>>
>> If setting this is not necessary, the line can be entirely removed.
>> ________________________________________________
>>
>> 2) Hard-coded image size in addImage() method.
>>
>> (This applies to ALL types of image, not just SVG.)
>>
>> In the MuseScore::addImage() function (file file.cpp, line 1700 and foll.),
>> which implements the "Add | Picture" contextual menu command for a frame,
>> the image size is set to a fixed 200x200 size (I think 200 raster units);
>> see line 1729:
>>
>> s->setSize(QSizeF(200, 200));
>>
>> I think this line is a left-over of some test / experiment and should be
>> deleted, allowing the image to keep its own size (the size is actually set
>> in the setPath() function called in line 1728).
>> ___________________________________________
>>
>> I made both changes in my local copy and I did not notice any negative side
>> effect. Comments?
>>
>> Thanks,
>>
>> M.
>>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [trunk] Two small details again about SVG embedding

Miwarre
lasconic wrote
All good for me too. I don't know if buffer.fill() is mandatory but a
known state is better than unknown.

Could you open a bug in the issue tracker and reference it in your
commit? or attach a patch to the issue if you want me to commit it for
you?

Lasconic
I have open 2 issues with attached relevant patches, committed them (with issue #'s in commit and Changelog) and marked as fixed. I think documentation should be complete.

Thanks,

M.
Loading...