Dave Harris
-
Posts
2,454 -
Joined
-
Last visited
Posts posted by Dave Harris
-
-
2 hours ago, Adriandw said:
@walt.farrell Thanks, you're right. It hadn't occurred to me to point to an existing anchor, but it works.
That's acceptable behaviour for a beta version.
But I'd hope that the production version would be smart enough to create a new anchor if necessary and to make use of an existing anchor where one existed, rather than create a second, duplicate anchor.That's what happens for me. When I insert a cross-reference to a paragraph, it creates an anchor at the start of that paragraph. If I insert a second cross-reference to the same paragraph, it reuses that existing anchor. This is in 1903.
Are all your anchors at the start of the paragraph, or are they spread through the paragraph? Was more text inserted in the paragraph after the first cross-reference was added?
-
We've tweaked this again for the next beta.
To explain a bit further... the problem with 1.x arose most with iPad. There's a touch-based UI where you can drag either end of the selection highlight. In 1.x it is fairly easy to drag the end of the selection highlight into blank text outside of the text box, and then you couldn't drag it back again. On desktop you can use the cursor keys, but on iPad screen real estate is so limited that the on-screen keyboard doesn't make the cursor keys available. While the problem is less on desktop, it would be good to find a common solution which didn't force the use of the keyboard on any platform. I had thought that if you were creating the blank lines by accident, then you would just delete them the first time they caused a problem.
In the next beta the behaviour will depend on whether the text is already selected. If it's not selected, you'll have to click in the visible box to select it. Once it is selected, you can click on the blank lines too. Hopefully this will fix the iPad issue when you are working with the text, without making it harder to select other objects when you aren't.
-
12 hours ago, GRAFKOM said:
Unfortunately, it's not fully fixed. If using Artistic Text and enter lines below the typed word, an invisible area appears that selects the text - without clicking on the text.
That's how it was before the fix. I note that in Affinity 1 it works correctly, i.e. even though empty lines are inserted with Enter, it is not possible to select the text by clicking below the entered text. The problem is presented in the video from the latest Beta. Please correct it.
That's now by design. The text caret and text highlight can be in the blank lines, so you need to be able to use the mouse in those lines too. It could a problem in 1.x that you couldn't.
Why do you need to create blank lines that don't draw?
-
7 hours ago, Intuos5 said:
[...]
6. Am I missing the option to go for paragraph numbers? Or even to take the number from a numbered list (I made the sources based on a numbered list here, so if I were to reference to any using [1], [2], [3], etc. formatting, I can use listnumber, but I can't use paragraph numbers only (numbered paragraph adds the text as well).
[...]
8. Is the idea that you can update a cross-reference preset and have it affect the existing cross references? Because if you make changes to the style of a cross-reference, you would now have to manually edit all of the cross-references. In Indesign, the preset you create can be modified and thereby affect all cross-references of the given style in the entire document, which is really the only way I would go about editing them. You should be able to make design changes more easily.
[...]
You can take the number from a numbered list by using the <List Number> field.
The idea is that you select multiple cross-references in the Cross-References panel, and that updates them all at once. You can sort the panel in different ways to make it easier to select the subset you want.
-
On 4/21/2023 at 2:43 PM, MikeTO said:
BTW since you're delaying CR to 2.2, you might consider addressing this minor suggestion which is somewhat important and was likely just an oversight.
Cross Reference panel should show source page number: The Cross References panel shows the cross ref name and target page number. ID shows the source page number which I believe is more useful. When I'm viewing my document and there are 10 cross references to "John Smith" I need to know which page each is on, not that they're all pointing to page 123.
Just to be clear, the panel currently shows the evaluated cross-reference text. That could be the page number, or it could be the content of the paragraph or "above/below". For the name we show the name of the target anchor. InDesign seems to show a partially-evaluated text, with page numbers showing as # but with the content of the target paragraph.
-
Thanks for the comments and suggestions. We plan to implement some of these, but it may take a little while.
We didn't provide Show as > Chapter Name because we figured the name of the chapter would normally be a heading somewhere in the chapter, so can be got by using the text paragraph body.
The Settings panel does include some document-specific settings. For example, the custom Filler text content which is also specific to the text language. While you are waiting for translations you can add your own strings. It is the spelling language from the Character panel that it uses. If that language is "English (US)" and that doesn't have a string, it will look for another variant of English instead, and similarly for other languages with regional variations.
-
As it happens, we do currently support simple kern pairs in the 'kern' table, but only the cross-platform version 0 variant. Optima uses version 1, which is Apple-specific. We'll add support for that in a future release.
-
Have you looked at Languages section in the Character panel? The Typography script and Typography language fields? Do they not work for you?
-
On 8/18/2021 at 8:22 PM, LibreTraining said:
Ligatures are an OpenType substitution (for the most part) where it is normal to keep the underlying characters.
But I do not see why AllCaps would do that - the user wants All Caps - that is not an OpenType substitution.
I do see any reason to not replace the characters (to avoid situations like this if nothing else).Maybe I am just used to apps like LibreOffice and Word where All Caps and Toggle Case actually replace the characters.
Which makes more sense to me.The reason for converting to capitals at draw time is so it can be switched on or off by text styles. For example, you might want a header style to be in ALL CAPS. Text styles shouldn't change the underlying text. It shouldn't cause any problems because OpenType features are applied to the ALL CAPS representation, and not to the underlying characters. As others have said, if you do want to change the underlying characters you can use the menu options that do that. It makes no difference to the result, because both methods use the same capitals conversion. (Which in this case maps U+00DF to U+0053 U+0053 and not to U+1E9E.)
-
On 8/18/2021 at 12:45 PM, Christoph Müller said:
I am not sure. I still think it's a bug in Affinity.
On the unicode.org page there is actually an FAQ article on this topic: https://unicode.org/faq/casemap_charprop.html#11
Briefly, it says that in German it is historically the case that a small sharp S is converted into a double capital S. That's why it's the standard in Unicode. But it also says that there may be the alternative of converting the small sharp S into a real capital sharp S.
In the DIN font, the character "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is defined as "SS" by default.
Accordingly, converting to uppercase in Affinity Designer from a "U+00DF ß LATIN SMALL LETTER SHARP S" to a "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" works correctly. If I enter "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" directly, "SS" is also displayed. This is also correct.
But now comes where I think the bug is:
Activating the stylistic set "German Capital Sharp S" basically does nothing other than switch an alternative appearance of the character "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" to the real capital sharp S (ẞ).
Thus, whenever a "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is displayed with the stylistic set "German Capital Sharp S" activated, Affinity Designer should always display a real capital sharp S (ẞ).
It should not matter whether the "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" was entered manually or was created by a conversion to capital letters.However, it only works when "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is entered directly. When converting a lowercase sharp S to uppercase, "SS" is still displayed.
Accordingly, I think it is a bug that the stylistic set "German Capital Sharp S" is not applied after converting to capital letters. Possibly this also applies to all stylistic sets.
Greetings,
ChristophActually, Affinity will apply the stylistic set after converting to capitals. The issue is that the capital conversion does not produce U+1E9E. It produces a pair of S (U+0053) instead. The stylistic set does not affect these.
It's unfortunate that this result is not what you want, but I'm not convinced that Affinity is doing anything wrong. The FAQ you cite confirms that the pair-of-S conversion is still the Unicode default, and other apps also use it. That's probably because so many fonts don't define U+1E9E, and capitalisation is not font-specific. If you know your font has a good definition of U+1E9E, you need to put it in manually.
-
Affinity apps do support Device N colour spaces for vector gradients. I've attached an example file that has a gradient between two spots, and between a spot and a process colour. I've also attached the exported PDF/X-1a that has the Device N shadings. I made this with 1.9.1, but the support has been there for a while. It does have to be a vector gradient with the fill tool, and not a gradient overlay filter effect or other raster gradient.
- Patrick Connor, Pauls and Alfred
-
3
-
Hi, I'm responsible for the back-end OpenType font support.
The issue with the Typography panel that we fixed recently was to do with Reverse Chaining Contextual Single Substitutions in the GSUB table. We just hadn't implemented them before, partly because we didn't have a font that used them to test with. That's also why we haven't implemented sampletext, tooltip and named parameters. If you could send a font that uses them to the link in Sean's post, that would be very useful.
-
Thanks for reporting this. The slow-down is indeed due to wrapping the text around the complex vector graphics. We used to calculate the default wrap outline a different way, which was fast but sometimes wrong where shapes overlapped. It is now correct, but much slower. To make matters worse, because the graphics are pinned, editing the text moves them and causes the wrap to be recalculated. I've logged this, and hopefully we'll have a fix for the next version.
-
On 9/19/2020 at 1:31 PM, Jens Krebs said:
What about showing the thumbnail preview image from the PDF instead?
In practice many/most PDFs don't include a thumbnail preview. Then the only way we can get an image to draw is to interpret the PDF ourselves, which will never be guaranteed perfect because the PDF specification will always have features we won't support. (Although supporting embedded fonts will help a lot.)
-
On 5/6/2020 at 10:13 PM, lookandlearn1976 said:
Please, please, please make a global default scale with object option!!! (unless of course it's a 1.8 feature I'm not seeing......). I feel like i'm fixing stroke widths more than anything else, on every illustration.
There is a global option to scale strokes with object. See my post above on June 27 2018.
-
On 4/11/2020 at 8:50 AM, Nebulosa said:
Why has the default Jpeg compression quality setting been changed from 85 in version 1.7 to 98 in version 1.8? I don't see any difference in quality, besides the size.
To give the better quality by default. We had some complaints that the images from Publisher were looked worse than from InDesign. If the 85% quality looks OK to you, feel free to make your own preset with the changed setting.
We would still like to have a 1.7 document that gives larger sizes than 1.8 when exported with the same settings. We will need this soon if it is to be fixed before 1.8.x. I've not been able to reproduce the problem using documents I've created myself.
-
On 3/2/2020 at 10:48 AM, designchris said:
If there was a global app-wide setting for that, I'd be happy!
Anyway, thanks everyone for joing this truly hot discussion!
You can use Edit > Defaults > Save to make the current defaults apply to new documents.
-
This should be better in 1.8 (released today). In 1.7.x, it tries to be clever about only showing OpenType options that are relevant to the selected text, but then it only looks at the first few characters and not the whole selection. In 1.8 it defaults to always showing the option (and lets you use it), and the cleverness is in trying to show good samples.
-
Could this be due to the interaction between Right indent and Last line indent? Does the indent behave as expected if you set them both to the same value?
We have a bug logged where increasing Right indent is supposed to increase the Last line indent automatically, but this wasn't working on Windows so you had to set them both manually. I'm not sure if this got fixed.
-
3 hours ago, woefi said:
Why do you "rasterise everything"?
Just a thought, but maybe it has to do with this setting...
Indeed. Rasterise: Everything will turn all the page content into a single bitmap. When that is done, options such as overprint and spot colours won't have any effect because the bitmap is just plain pixel data. It's intended for either when Affinity Photo just wants to wrap its final image in a PDF, or for when some dire bug means the vector export isn't working as intended and there's no other way to get any output. The default option is to only rasterise features PDF doesn't support, and that should be the best.
Note Rasterise: Unsupported properties will rasterise transparency for PDF versions that don't support it, namely PDF/X1-a and PDF/X-3. If your printer is requesting Rasterise: Everything because they think it rasterises transparency only, then you may need to use one of those.
-
2 hours ago, Lagarto said:
Good to know. Is this something that non-Affinity apps know, as well, or proprietary data saved off-the-file by Affinity apps / documents?
It's stored with the rest of the image data in the Affinity document. Our file format isn't documented and shouldn't be a concern of other apps. It should just mean that importing a PDF and then exporting it repeatedly won't degrade the image.
-
2 hours ago, Lagarto said:
Normally PDF compression is a one-time procedure and does not accumulate but now that people can open PDF files (and seem to frequently do so, especially with Affinity apps), there is a danger that PDF files are treated as a kind of standard documents, and then the compression effect would also accumulate and quality of exported images get increasingly worse.
Affinity will store the compressed data from the PDF in that case, and will only recompress if something is done to the image.
-
The default autocorrect includes dash dash => en-dash. This is less likely to trigger by accident than dash => en-dash.
It looks like it is trying to do en-dash dash => em-dash, but it doesn't work well partly because the autocorrect doesn't kick in until you type a space, and then the space breaks up the pattern. It should have dash dash dash => em-dash instead.
-
20 hours ago, ernie-f said:
1. Widows and orphans are not set correctly.
Can you upload a document where they are set wrong, so we can see what is happening and fix it?
Cross References
in [ARCHIVE] 2.4, 2.3, 2.2 & 2.1 Features and Improvements
Posted
It looks like updating a Table of Contents can modify or delete the anchors used by hyperlinks and cross-references so that links to them break. TOC also puts its anchors at the end of the paragraph, and cross-references only looks for anchors to reuse at the beginning. I think this explains at least some of what you saw.