Jump to content

Recommended Posts

PowerBASIC. The best and fastest programming language in the world. Made completelly in assembler and you can write in assember inside it.

 

http://www.powerbasic.com/

 

:)


Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
Share on other sites

In the 1.5 beta, the text size controls will support variables:

        x, a, c

        xheight, ascent, capheight

 

So "12pt / x" will make the text x-height be 12pt.

I might be a bit dense right here at this point but if anyone can explain to me why I need to type 12pt /x to get a x height of 12pt, I´d appreciate that info!

The " / "sign is confusing me... :ph34r:

 

 

+ even more units/ expressions available https://forum.affinity.serif.com/index.php?/topic/23154-transform-value-fields-repeatable-crash/?p=109026


 

 

Share this post


Link to post
Share on other sites

The syntax is this way because it is based on our standard expression evaluation. I didn't add any new syntax, I just added some new variables. So what you type is determined by algebra. The "/" means division. "x" means ratio of the x-height to the font height, which is the x-height when the font has a height of 1 unit. The value we're entering into the control is the height, so that's what we need an expression to calculate. For an x-height of 12pt, we have 12pt = height * x, and so height = 12pt / x.

 

It may not be ideal, but I figured no syntax would really be easy and most people would just learn what to type. If they find it at all. It's not very discoverable, but I don't think any other syntax would be either, until we get some kind of pop-up help for it.

Share this post


Link to post
Share on other sites

I might be a bit dense right here at this point but if anyone can explain to me why I need to type 12pt /x to get a x height of 12pt, I´d appreciate that info!

The " / "sign is confusing me... :ph34r:

 

Well, yes. Seems to be math. ;-) Already explained here.

 

HTH

 

Sorry, Dave was quicker and better. Perhaps a "hover” hint with Affinity Help link is a solution.

Share this post


Link to post
Share on other sites

It's not very discoverable, but I don't think any other syntax would be either, until we get some kind of pop-up help for it.

 

Perhaps a "hover” hint with Affinity Help link is a solution. New units like xp and xm would be not ideal. A new pop-down for selecting x, a, c, … needs more place. :-(

Share this post


Link to post
Share on other sites

If I set the document setup to 72 dpi and type in /x after the font size, then the font size changes

 

As I´ve read, 1pt = 1/72th of an inch so at a document resolution of 72ppi 1pt = 1px

Anyhow, thanks for your answer, I´ll give it some thought at some point when I need to know about it, obviously it´s a fault on my end and not in your implementation

 

Thanks for your answers both!! 


 

 

Share this post


Link to post
Share on other sites

If I set the document setup to 72 dpi and type in /x after the font size, then the font size changes

 

Of course. First: That has nothing to do with the 72 dpi. Second: The x-height of a font has not very much to with the “Text Height” or your “font size”, because the Text Height (point size) is still defined as a very free body height. Sorry, it is not easy to explain in a sentence, but got it?

 

PS: 10 pt Text Height “never” results in text that is 1/72*2,54*10*10 mm heigh. But in many cases if you use c in the Text Height field.

 

26377375xx.jpg

Share this post


Link to post
Share on other sites

The standard units are:

        px, pix, pixels - pixels

        in, ins, inch, inches - inches

        pt , pts, point, points - point

        mm - millimetre

        cm - centimetre

        m - metre

        ft, foot, feet - foot

        yd, yds, yard, yards - yard

        cat, cats - cat

 

        °, ˚, deg,  degs, degree, degrees - degrees

        rad, rads, radian, radians - radians

 

        pc, perc, percent - percentage

        ‰, permille - permille

 

The standard variables are:

            pi Pi, PI ,π - pi

           phi, Phi, PHI, gr, GR, φ - the golden ratio

            root2, rad2, rt2 - the square root of 2

 

The Transform tab supports variables:

        x,  y, w, h, r, s,

        xposition, yposition, width, height, rotation, shear

 

The Document properties supports variables:

       w, h, l, r, t, b,

       spreadwidth, spreadheight, marginleft, marginright, margintop, marginbottom

 

In the 1.5 beta, the text size controls will support variables:

        x, a, c

        xheight, ascent, capheight

 

So "12pt / x" will make the text x-height be 12pt.

 

We don't plan to allow user-defined units. We did intent to support " and ' for inches and feet, but that doesn't seem to be working in the current release. I'll fix it for 1.5 beta.

 

Is this included in Help files?


Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
Share on other sites

Is this included in Help files?

 

Well, you have the beta, right? Not everything is in Affinity Help because the doc team gets green light from the dev team. Described somewhere in the forum.

Share this post


Link to post
Share on other sites

Well, a user-defined unit would need some extra user interface to define it, and it would need to be stored in the document, which makes it different to all our existing units. Currently you can change the number of decimal places for units in Preferences, and that would need to be re-thought now the list of units is not fixed. It's all doable, but it takes more time than we'd like.

 

What other units do you need? Bear in mind that inch-marks and foot-marks were supposed to be including from the beginning, and it's a bug that they don't work. They will work in 1.5.

 

Well, in Japan, I think, they use "q" as a unit which is equal to 1/4 of a "mm". Beside this, I would preffer "t" that is equal to 1/10 of a "mm".

A suggestion: When "Show text in points" is deselected in "Preferences", the values in "Text height" are shown in millimeters converted from points (in my case). It would be nice to have values like these: hairline, 0,1mm, 0,2mm, 0,5mm, 1mm... In this case, "q" and "t" units would be obsolete.


Windows 10 x64 Pro
Dell Inspiron 7559 i7
Intel Core i7-6700HQ (3.50 GHz, 6M )
16GB Dual Channel DDR3L 1600MHz (8GBx2)
1TB HDD + 128 GB SSD Hard drive
UHD (3840 x 2160) Truelife LED- Backlit Touch Display
NVIDIA GeForce GTX 960M 4GB GDDR5

Share this post


Link to post
Share on other sites

Sorry for chiming in late but for web design it would be really useful to be able to have the em unit, too. I understand that this is a relative unit and needs some fairly advanced calculations to a reference pixel but it would help tremendously to design truely responsive and device-independent websites without requiring to do that in the browser. That would include setting either the document or artboard dimensions in em (think CSS media queries) as well as showing object dimensions in the transform panel and distances in the document in em. Would that be feasible?

Share this post


Link to post
Share on other sites

I understand that [the em unit] is a relative unit

 

In particular, ems are relative to point size. So how would this work when a document contains a mixture of point sizes (which most documents do)? :unsure:


Alfred online2long.gif
Affinity Designer/Photo/Publisher 1.7.3.481 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.3.155 • Designer for iPad 1.7.3.1 • iOS 12.4.1 (iPad Air 2)

Share this post


Link to post
Share on other sites

In particular, ems are relative to point size. So how would this work when a document contains a mixture of point sizes (which most documents do)? :unsure:

 

Same with x, a, c and every text height. So why do you ask?

Share this post


Link to post
Share on other sites

Same with x, a, c and every text height.

 

Yes, but ... x, a and c are variables (unlike ems, points, pixels and cats).


Alfred online2long.gif
Affinity Designer/Photo/Publisher 1.7.3.481 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.3.155 • Designer for iPad 1.7.3.1 • iOS 12.4.1 (iPad Air 2)

Share this post


Link to post
Share on other sites

Yes, but ... x, a and c are variables (unlike ems, points, pixels and cats).

 

Doesn’t matter how you call it. They all (em, x, text height, …) depend on a chosen font. So again, why do you ask? Do you want to write the concept and code?

Share this post


Link to post
Share on other sites

Same with x, a, c and every text height. So why do you ask?

x, a and c only work in the text height controls, so they can be relative to the font they are applying to. Using em for the size of an artboard is different because an artboard might contain no text, or text with many different sizes and fonts.

Share this post


Link to post
Share on other sites

x, a and c only work in the text height controls, so they can be relative to the font they are applying to.

Using em for the size of an artboard is different because an artboard might contain no text, or text with many different sizes and fonts.

 

Are there situations they are not relative?

So there are/will be two different em’s? How is that artboard-em defined?

Share this post


Link to post
Share on other sites

Right, now that you mention it – ems in HTML/CSS are relative to the (calculated) font size of the element to which they are applied. So, a rectangle you draw in AD could never know an exact em value because objects in AD aren’t necessarily in a parent/child relationship, especially not to something with a font size (and you can’t apply a font size to a layer or group or whatever).

Nevermind then.

Share this post


Link to post
Share on other sites

Are there situations they are not relative?

 

No. They must be relative to a font, but that's OK because in the text height control they can be relative to a font.

 

I think using em for artboards would be equivalent to implementing user-defined units. It's not something we are currently planning to do.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.