Petar Petrenko Posted April 10, 2016 Share Posted April 10, 2016 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/ :) Quote All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows. 15” Dell Inspiron 7559 i7 ● Windows 10 x64 Pro ● Intel Core i7-6700HQ (3.50 GHz, 6M) ● 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) ● NVIDIA GeForce GTX 960M 4 GB GDDR5 ● 500 GB SSD + 1 TB HDD ● UHD (3840 x 2160) Truelife LED - Backlit Touch Display 32” LG 32UN650-W display ● 3840 x 2160 UHD, IPS, HDR10 ● Color Gamut: DCI-P3 95%, Color Calibrated ● 2 x HDMI, 1 x DisplayPort 13.3” MacBook Pro (2017) ● Ventura 13.6 ● Intel Core i7 (3.50 GHz Dual Core) ● 16 GB 2133 MHz LPDDR3 ● Intel Iris Plus Graphics 650 1536 MB ● 500 GB SSD ● Retina Display (3360 x 2100) Link to comment Share on other sites More sharing options...
anon1 Posted August 1, 2016 Share Posted August 1, 2016 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 Quote Link to comment Share on other sites More sharing options...
Dave Harris Posted August 1, 2016 Share Posted August 1, 2016 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. Oval 1 Quote Link to comment Share on other sites More sharing options...
Oval Posted August 1, 2016 Author Share Posted August 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
Oval Posted August 1, 2016 Author Share Posted August 1, 2016 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. :-( Quote Link to comment Share on other sites More sharing options...
anon1 Posted August 1, 2016 Share Posted August 1, 2016 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!! Quote Link to comment Share on other sites More sharing options...
Oval Posted August 1, 2016 Author Share Posted August 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
Petar Petrenko Posted August 1, 2016 Share Posted August 1, 2016 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? Quote All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows. 15” Dell Inspiron 7559 i7 ● Windows 10 x64 Pro ● Intel Core i7-6700HQ (3.50 GHz, 6M) ● 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) ● NVIDIA GeForce GTX 960M 4 GB GDDR5 ● 500 GB SSD + 1 TB HDD ● UHD (3840 x 2160) Truelife LED - Backlit Touch Display 32” LG 32UN650-W display ● 3840 x 2160 UHD, IPS, HDR10 ● Color Gamut: DCI-P3 95%, Color Calibrated ● 2 x HDMI, 1 x DisplayPort 13.3” MacBook Pro (2017) ● Ventura 13.6 ● Intel Core i7 (3.50 GHz Dual Core) ● 16 GB 2133 MHz LPDDR3 ● Intel Iris Plus Graphics 650 1536 MB ● 500 GB SSD ● Retina Display (3360 x 2100) Link to comment Share on other sites More sharing options...
Oval Posted August 1, 2016 Author Share Posted August 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
Petar Petrenko Posted August 19, 2016 Share Posted August 19, 2016 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. Quote All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows. 15” Dell Inspiron 7559 i7 ● Windows 10 x64 Pro ● Intel Core i7-6700HQ (3.50 GHz, 6M) ● 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) ● NVIDIA GeForce GTX 960M 4 GB GDDR5 ● 500 GB SSD + 1 TB HDD ● UHD (3840 x 2160) Truelife LED - Backlit Touch Display 32” LG 32UN650-W display ● 3840 x 2160 UHD, IPS, HDR10 ● Color Gamut: DCI-P3 95%, Color Calibrated ● 2 x HDMI, 1 x DisplayPort 13.3” MacBook Pro (2017) ● Ventura 13.6 ● Intel Core i7 (3.50 GHz Dual Core) ● 16 GB 2133 MHz LPDDR3 ● Intel Iris Plus Graphics 650 1536 MB ● 500 GB SSD ● Retina Display (3360 x 2100) Link to comment Share on other sites More sharing options...
VIPStephan Posted August 19, 2016 Share Posted August 19, 2016 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? Quote Link to comment Share on other sites More sharing options...
Alfred Posted August 19, 2016 Share Posted August 19, 2016 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: Quote Alfred Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen) Link to comment Share on other sites More sharing options...
Oval Posted August 19, 2016 Author Share Posted August 19, 2016 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? Quote Link to comment Share on other sites More sharing options...
Alfred Posted August 19, 2016 Share Posted August 19, 2016 Same with x, a, c and every text height. Yes, but ... x, a and c are variables (unlike ems, points, pixels and cats). Quote Alfred Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen) Link to comment Share on other sites More sharing options...
Oval Posted August 19, 2016 Author Share Posted August 19, 2016 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? Quote Link to comment Share on other sites More sharing options...
Dave Harris Posted August 19, 2016 Share Posted August 19, 2016 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. Alfred 1 Quote Link to comment Share on other sites More sharing options...
Oval Posted August 19, 2016 Author Share Posted August 19, 2016 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? Quote Link to comment Share on other sites More sharing options...
VIPStephan Posted August 19, 2016 Share Posted August 19, 2016 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. Quote Link to comment Share on other sites More sharing options...
Dave Harris Posted August 20, 2016 Share Posted August 20, 2016 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.