The handling of SVG by Processing is deliberately simple, to keep it small. If you need something more powerful, perhaps a library like Batik is more necessary.
Processing doesn't compute the size of shapes, because it is quite difficult to do. I suppose you can compute the min and max of a path, but even this isn't enough: I can make a shape with two points aligned vertically, that extends very wide horizontally, way beyond the control points.
That, and the fact a shape can be in a g group, itself in another g group, etc., each with scale, translate, rotation, etc.
So, Processing doesn't even try to compute these dimensions, even for simple shapes.

Thanks for that suggestion; I’ll consider Batik in the future.

As a beginner though, I’m still trying to understand the operations of Processing with basic shapes. This has been my progress as I’ve read and practiced the many examples provided at several web sites:

• Learn to draw basic shapes in Processing.
• Learn Class object methods.
• Generate shapes in Inkscape with one shape per file, with page same size as shape; learn svg.
• Generate multiple shapes on one page/file, assigning id names.
• Learn to read match getChild() shapes to Class objects.

In the last step I ran into a problem because the location and size modifications don’t work as they do when drawing the shapes in Processing. And the Reference doesn’t mention any differences.

Processing doesn't compute the size of shapes, because it is quite difficult to do.

I wasn’t expecting Processing to compute anything. For size modification, I was only suggesting they utilize the existing information (already in the svg file), namely the width and height values for each shape id name, e.g.:

1.     <rect
2.        style="fill:#ff0000;fill-opacity:1;stroke:none"
3.        id="door"
4.        width="60" // need this
5.        height="100"  // need this

  What Processing does now is misleading, saying that the shape’s dimensions (e.g. door.width) are equal to the page. 

The Page dimensions are provided at the beginning of the svg file; I’m not sure why I’ll ever need the page size in Processing. But I do know it would be helpful to have the child dimensions.

In the meantime, my latest two getChild() threads have provided “x,y” and “size” workarounds; they are really not that difficult.

 

rect has width and height, but most other shapes, and the most common one in SVG, path, doesn't has this. Processing hasn't made a special treatment for rect. And as I wrote, your rect can be scaled, rotated, etc. What is its size in this case?
PShapeSVG is used for all the types of SVG shapes, from the page itself (hence the width and height taken from the svg tag) to the smallest inner shape, including the g groups and so on. That's why you have some fields, like width and height, that are relevant for some shapes but not for the others. A bit unfortunate, but in the line of "keep it simple", the general philosophy of Processing.

but most other shapes, and the most common one in SVG, path, doesn't has this.

You’re right, the SVG for path does not have explicit Width and Height values, even if the original object was a rectangle.

But I think you’re missing the point of my thread:

1.      I gave an example of three rectangles in a page, not 3 paths.  

2.      As a beginner, I didn’t know about paths yet. The word “path” does not even appear in Processing Reference.

http://processing.org/reference/shape_.html

First, Reference getChild() does not help much:

• ·        It does not say that a child shape is recognized by an “id”
• ·        It does not even mention shapes!

http://processing.org/reference/XMLElement_getChild_.html

How can the Processing programmer proceed without this information?

 

Second, getChild() doesn’t seem to agree with Object-oriented programming, where class objects have unique properties and methods. An object class can inherit certain things from other classes, similar to actual children inheriting from parents. When I saw getChild() in Processing, I assumed this meant that whatever is “gotten” is an object like those made from a Class.

Say I make a class House to be a rectangle and construct object “house1” to be 60w x 100h. That is the object’s Width and Height. When it’s displayed in a sketch with size(400, 400), the object “house1” does not change its Width and Height to  “400 x 400”.   

But that’s what happens with getChild() shapes. If shapes “house1” (60w x 100h) and “door1” (10w x 30h) come from an Inkscape svg file with Page size 400w x 300h, both house1.width and door1.width are 400!

It’s more like getChildWithPage().

However, the workaround that I described recognizes that situation. A simple explanation in Reference would save much time for beginners.

 

You’re right, the SVG for path does not have explicit Width and Height values.

But for non-path objects that do have them, why not provide that information to the programmer?

• ·        The subordinate shapes have their own width and height; they are properties that belong to them.
• ·        If I need child.width, I don’t want page.width.

Consider the millions who prefer to utilize rectangle instead of path.

Processing doesn't compute the size of shapes, because it is quite difficult to do.

Actually Processing must compute the size of shapes.

After learning basic path ideas, I made a sketch (rectangleChildren_paths.pde) in which rectangle paths are displayed correctly after shape() is used with new Width and Height values. Shape() does not have path parameters.

Therefore, Processing must compute path data and determine the shape. If it meets certain criteria (quite difficult!), it knows if shape() can alter it with Width and Height values.   

And as I wrote, your rect can be scaled, rotated, etc.

Please try this.

In Inkscape draw a rectangle 100w x 200h, within the default page. Select and call it “rec1”.

Draw another rectangle; convert it to a path. Call it “path1”. Save the file and copy it to a Processing sketch Data folder.

With instructions only found in Reference, please let me know how you:

• ·        display rec1 and path1
• ·        use scale() to change their  size

The sketch will look like this:

1. PShape main, rec1, path1;
2. void setup()
3. {
4.   size(400, 400);
5.   main = loadShape("xxx.svg");
6.   rec1 = main.getChild(“rec1”); // rectangle shape
7.   path1 = main.getChild(“path1”); // rectangle shape converted to path
8. }
9. void draw()
10. {
11.   shape(rec1);
12. } 

 

" Consider the millions who prefer to utilize rectangle instead of path."
Actually, rectangles and other simple shapes are quite scarce in SVG files made by drawing tools! And there is little point to extract individual rectangles from a SVG. It is much simpler and faster to use rect()...

I won't dispute the fact that the reference can (and should) be improved.
Indeed, perhaps if dimensions are found in some primitive shape, perhaps it could be used, but again, the shape can be in a g group with transform, so I don't know if the information is useful.

" getChild() doesn’t seem to agree with Object-oriented programming [...] I assumed this meant that whatever is “gotten” is an object like those made from a Class."
getChild() returns an object, an instance of a class, a PShape, or more exactly, a PShapeSVG.

Note that Processing isn't strongly object-oriented, it deliberately chose the procedural paradigm for most of its API, as it is simpler for beginners.