We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4072 - SVG images : add a parameter to control scaling of images
Summary: SVG images : add a parameter to control scaling of images
Status: NEW
Alias: None
Product: SDL_image
Classification: Unclassified
Component: misc (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-08 09:28 UTC by Sylvain
Modified: 2020-05-15 18:17 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain 2018-02-08 09:28:21 UTC 
SDL_image handles SVG image. It currently loads them with their original width/heigh.

It would be nice to be able to use the rasterized scale parameter, so that those images could be loaded with any width/height. (it's not possible to modify the aspect ratio though). 


To have this done use in one pass (in IMG_LoadSVG_RW), we can think of 4 modes: 

none: current behaviour, scale is 1.0f. Output surface is (image->width) x (image->height).

user_scale: user provides scale parameter. Output surface is (image->width * user_scale) x (image->height * user_scale). The drawback with this, is that user doesn't know in advance the output width/height.

user_width: user provides output width. So scale is computed as (user_width / image->width). Output surface is (user_width) x (image->height * (user_width / image->width)).

user_height: user provides output height. So scale is computed as (user_height / image->height). Output surface is (image->width * (user_height / image->height)) x (user_height).


I think that the purpose of vector images to control the scale parameter !
Comment 1 Dan Lawrence 2020-05-15 18:17:08 UTC 
The current behaviour of SVG is a little odd, it seems to create the surface size based on the values defined in the svg files 'width' and 'height' parameters. e.g.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 60 30" preserveAspectRatio="none" width="240" height="120">
<clipPath id="s">
	<path d="M0,0 v30 h60 v-30 z"/>
</clipPath>
<clipPath id="t">
	<path d="M30,15 h30 v15 z v15 h-30 z h-30 v-15 z v-15 h30 z"/>
</clipPath>
<g clip-path="url(#s)">
	<path d="M0,0 v30 h60 v-30 z" fill="#012169"/>
	<path d="M0,0 L60,30 M60,0 L0,30" stroke="#fff" stroke-width="6"/>
	<path d="M0,0 L60,30 M60,0 L0,30" clip-path="url(#t)" stroke="#C8102E" stroke-width="4"/>
	<path d="M30,0 v30 M0,15 h60" stroke="#fff" stroke-width="10"/>
	<path d="M30,0 v30 M0,15 h60" stroke="#C8102E" stroke-width="6"/>
</g>
</svg>

The SVG file will load onto a surface that is 240x120 pixels, but the image of the flag it contains will only be 60x30 pixels

I think a more useful default behaviour here would be to scale the flag's width to match the surface's width in the rasterize step. 

Unless I'm getting something wrong - I am loading at a remove via pygame.