Jump to content

anweid

Members
  • Content count

    56
  • Joined

  • Last visited

About anweid

  • Rank
    Member

Recent Profile Visitors

197 profile views
  1. In update 206, most of the above problems seem to be solved - thanks. But not all... Some of the mentioned problems still remain. Fortunately, they are now easier to spot, because the style settings text in the Create Paragraph Style dialog is now not so cluttered anymore. Before the attached video starts, I just created a new document, right-clicked on the base group style and selected Create Style Based on. When the dialog opens up, everything seems to be correct at first glance. Selecting Position & Transform, though, still shows zeroes for kerning, tracking, baseline and leading (as mentioned before), even though these should be set to [no change]. Manually selecting [no change] in the drop-downs now show up as zeroes in the style settings text at the bottom of the dialog. Apparently, there is come mix-up of the settings 0 and [no change]. It would be nice if these four settings worked as nicely as the other ones... Andreas Weidner PositionTransformProblems.mp4
  2. Affinity Publisher 1.7.0.192 on a German Windows 7 (64bit) behaves as follows: The studio panels headers can be collapsed, which works nicely. The expanding does not always work nicely, though. In the attached video, the Table studio's headers are all expanded at 0:00. Collapsing them all around 0:11 works properly. Expanding them around 0:16 does not use up more screen space as desired, but only the space previously occupied by the collapsed headers, and instead shows a scroll bar. Only by switching to a different studio and back again makes all expanded headers display as desired. After seeing this happen several times and creating the video, I could not reliably recreate this misbehaviour again, so I don't know under what circumstances it can be observed (at the moment, the expanding works properly again). Andreas Weidner NoPanelExpand.mp4
  3. I even managed to capture some extreme weirdness on video with Affinity Publisher 1.7.0.192 on a German Windows 7 (64bit). The weird behaviour of bullets seems to be connected to the (still rather buggy) text styles dialog - at least only the bullets that used a dedicated character style did strange things. Hints: In the attached document, I created the 'Bullet' paragraph style, which uses the 'Large' character style for the bullets (yes, the bullets are much too large, I know). The 'Large' style once was defined by me with fontsize=30pt and baseline=-6pt. Unfortunately, you will not be able to see this in the document: By some mysterious reason, after defining the character style this way in the Edit Text Styles dialog, closing the dialog and opening it again, the previously set baseline of '-6pt' is converted to '25pt', and the baseline used in the actual document is more something like +6pt. And the bullet size in the document is also not 30pt, but something less. Weird. This is the beginning of the video. I do not know exactly anymore how I got to the beginning of the video: My first tries to get some strange behaviour failed, so I just clicked wildly around, changed several styles, typed, did undos etc. And lo! suddenly, there was weirdness! At 0:00, the bullets that should be fontsize=30pt and baseline=-6pt are smaller and positioned higher. Opening the Edit Text Styles dialog even shows these settings in the description at the bottom at 0:11. The Font page also shows 30pt text size at 0:22, even though the bullet size is not 30pt. The Position & Transform page at 0:27 shows the mentioned wrong '25pt' baseline, even though -6pt were requested, and about +6pt are used in the document. Changing the baseline with the mouse to 26pt at 0:36 immediately makes the bullets really jump to 26pt and - watch! - the bullet size increase to really 30pt. Clicking with the mouse to decrease the baseline down to -5pt leaves fontsize=30pt and baseline=AsDesired. But - watch! - when decreasing the baseline to -6pt (where it should have been from the beginning) at 0:53, the font size gets smaller again and the baseline jumps back to around +6pt instead of -6pt. Fascinating! Whatever weird things happen here, some of this weirdness is somehow saved somewhere, because saving the document in this state and opening it again restores that weirdness. Of course it would be nicer if things were working more reliably... Andreas Weidner WeirdBullets.mp4 WeirdBullets.afpub
  4. In all the 'Affinities' of all versions that I ever remember, the font drowdown is divided into groups, each of which contains all variants of this font. Fine. When hovering the mouse above a variant, the text preview inside the document is always correct. But when hovering the mouse above a font group, sometimes the resulting text preview switches to italics and/or bold, which I think is unwanted... In the attached video, you can see The font group 'Rounded' at 0:06, which shows the correct preview. The font group 'Rounded Condensed' at 0:09 shows the correct preview in the combo, but an italic preview in the document. When expanding the group, all 4 variants are properly shown, and their document previews are also correct. The font group 'Rounded Expanded' at 0:22 shows the correct preview in the combo, but a bold-italic preview in the document. The variants work properly as stated. At 0:50, the same happens with a bold-italic 'TheSans' and at 0:59 with an italic 'TheSans Black'. It would be nice if the group previews inside the document matched the ones in the combobox and were displayed without italics or bold (if available). The overwhelming majority of fonts work properly in this respect - only with a handful of fonts I encounter this problem. It could of course be a problem with the fonts themselves, but since all other programs I tested always show the correct preview (including PagePlus), and the combobox also does, I take it that something's wrong with the Affinities. In case you cannot find a font that makes this happen, please tell me where to non-publicly sent the font files - I don't want to be killed by neither the font designer nor the foundry for publicly distributing their work... Andreas Weidner FontPreview.mp4
  5. As a matter of fact, Publisher 1.7.0.192 on a German Windows 7 (64bit) even has problem reading its own PDF exports, at least if OpenType features are used in the document. The attached Publisher file contains several alphabets (Consolas font) with different OpenType features. The exported PDF looks correct, but trying to import this PDF in Publisher again results in wrong characters at every place where an OpenType-featured character was situated. Andreas Weidner PDFProblems.pdf PDFProblems.afpub
  6. I have also had several problems with the reliability of character styles in bulleted lists: Sometimes, the character style was used properly, but sometimes not. In the same document, only a few paragraphs away, some bullets were OK (and used the defined character style), but others weren't (the bullets appeared properly, but did not use the defined character style). I couldn't find a way to decently reproduce this wrong behaviour, so I didn't write a report yet. The only (strange) solution I found at that time was: Edit the character style to something undesired. Edit the character style back to the desired settings. Voilà: All problematic bullets changed to the desired style (but in a few minutes, newly created lists would again ignore the character style by some reason). Just trying to reapply the paragraph style did not work in most cases. Andreas Weidner
  7. Several minutes ago, I misclicked and tried to place an apparently defective BMP file into Affinity Designer 1.6.5.123 on a German Windows 7 (64bit). The program showed a crash dialog and exited. Being curious, I tried the import again with Publisher 1.7.0.192, which immediately stopped responding without crash report and had to be killed manually. Yes, the image file is corrupted - apparently, the program with which I wanted to save the file crashed during saving (several years ago), and I forgot to delete the remaining corpse afterwards. But of course it would be nicer if the Affinites wouldn't crash in such a case, but just show a corresponding error message. Andreas Weidner StolenMoments01.bmp
  8. All 'Affinities' have the ability to place bitmaps in their documents, which can be zoomed, rotated etc. as desired. By some reason, these bitmaps are not placed as 'bitmap' objects, but 'image' objects. This apparently makes it impossible to, e.g., use Designer's bitmap facilities to edit them: When selecting a newly placed bitmap and trying any of the functions from the Pixel Persona, I'm told that a new pixel layer was created, so the selected bitmap cannot be made transparent with that. When rasterising the image, it is automatically re-rasterised with the current document resolution, which in roughly 100% of all cases is not equal to the placed bitmap resolution, so the image changes and becomes blurred by the rasterising, which is undesired. Trying to edit the placed image directly in Affinity Photo doesn't work, either, because when selecting the menu item Edit in Affinity Photo, the whole document is rasterised with the document resolution, which is still undesired. In PagePlus, after selecting a bitmap, it is possible to directly edit this bitmap with PhotoPlus, and no matter how large or rotated the bitmap is, PhotoPlus is opened with the original bitmap, and one can edit this. Wonderful! Whatever I tried with the Affinities, I could not find anything similar. Either it didn't work at all, or the bitmap was wrongly re-rasterised. Is there any function planned that can do this (or perhaps it's already available, but hidden somewhere I didn't look)? I often work with bitmaps from the clipboard, and the only possibility I found was not pasting the clipboard into Designer or Publisher, but first pasting it into Photo, changing it there, saving it as a file on disk and importing it into Designer or Publisher. This seems to be much more inconvenient than with PagePlus, and especially a waste of the nice Pixel Persona functions in Designer, which I now can not make use of due to the problematic re-rasterisation... Andreas Weidner PS: Of course this doesn't really matter with high-resolution real-world photos, which probably look good whether re-rasterised or not. But I'm using lots of very small GUI screenshots with pixel sizes of 16x16, 32x32 or other stuff like that. Re-rasterising such miniatures creates quite visible changes, and the resulting blur doesn't look too good. And increasing the document resolution to 1200dpi or so seems a waste of resources and would later create unnecessarily large PDFs.
  9. anweid

    Live filters depend on zoom

    Thanks for the info. This is what I suspected when comparing the high speed of the live filters with the much slower layer combining... But anyway - this perhaps is a point that should be mentioned somewhere in the help pages, e.g. under 'working with live filters'. At least I first looked there before posting, but didn't find anything. Andreas Weidner
  10. I don't know whether or not this is a bug or a mathematically necessary problem, but I just mention it anyway. In Affinity Photo Beta 1.7.0.188 and at least the previous versions 1.6.x on a German Windows 7 (64bit), the live filter's results depend on the current zoom of the image on-screen. The attached video should probably be downloaded and watched at 100% (1 pixel = 1 pixel) for best results: The picture is scanned from a cooking book, so the print resolution is easily visible at 100%. Changing the zoom in such a picture of course creates lots of strange patterns appearing on screen (0:10-0:20). This cannot be avoided. In order to get rid of this, around 0:23 I use a live filter to blur the image considerably, which it does nicely. The print resolution disappears, but of course the image is not sharp anymore. Looking at this blurred image with different zooms (0:26-0:40), one can still see some moirés appearing, so it is very hard to decently judge the overall quality of the blur. It appears as if the blur was not enough to get rid of the print resolution. I leave the picture at 32.8%, because here the moirés are best noticable. Around 0:46, I combine all layers into one, which takes some time. After the combination, all moirés instantly disappear, even though the zoom wasn't changed. The moirés therefore were introduced by the live filter not doing exactly what it could do, but something else. Whatever the zoom of this combined layer, no moiré ever appears. This of course is nice and should be achieved. Unfortunately, this cannot be judged decently with the use of a live filter, because this apparently does yields results that depend on the current zoom. It might be that the live filters, probably due to speed considerations, don't take all image information into account, but only the currently visible information, and therefore yield zoom-dependent results. If that's the case, I'm of course not happy, but at least I know that this is how it should be. If that is not an expected behaviour - well, then you have something to think about... In case you would like to get the corresponding Affinity Photo file, please tell me how and where to send it - since it's about 50MB large, I surely get a time-out within this forum, because I only have very limited upload speed. Andreas Weidner LiveMoires.mp4
  11. Screen recording attached. Some hints: Until 1:00, I just create a new document with two layers, one of them masked. From 1:01 to 1:10, I Alt+click the mask to show it in grayscale to make its contents decently visible. Around 1:19, I resize the document. In this case, only horizontally, but the error also happens with equal scaling in both directions. The resulting image at 1:30 looks correct. Around 1:36, the undo is done. The resulting image looks similar to the previous one, but it's not the same. Around 1:40, I Alt+click the mask again. It is not the same mask as previously: The undo has done damage horizontally (vertical seems to be OK). Not shown: If I scale equally in both directions, the following undo also destroys the mask scale in both directions. If I may hazard a guess what the problem might be: It looks to me as if your undo algorithm would undo the mask scaling twice instead of once. Attached is also a similar file for you to try... Andreas Weidner DestroyedMask.mp4 DestroyedMask.afphoto
  12. I agree to your first paragraph where you claim 'the boxes [...] should be shown during Basic mode'. Yes, but if you look at the video, they are not shown in Basic mode. For your second paragraph, I strongly disagree: Please take a look at Affinity Designer 1.6.x, which does it correctly: In the previous version, automatic mode shows the edit fields, but keeps them disabled (as 1.7.0.188), which is OK. But using simple mode (or basic, I don't know how this is called in English, because I just see German texts) shows the two edit fields and lets you edit them. That is exactly the correct behaviour. What would be the use of a basic grid if the user cannot change its settings, but has to go to advanced grid to change them, or to automatic grid to see the settings? The settings for the basic grid should be done in the basic grid as previously, and not in the advanced grid, otherwise nobody would need a basic grid anymore. Setting up a nice grid in version 1.6.x is so wonderful, but in 1.7.0.188, it does not work anymore. Please revert to the old wonderful behaviour, which is much more logical and intuitive than the current beta state (which I still consider a bug and not a feature). Andreas Weidner
  13. Affinity Designer 1.7.0.188 offers construction snapping, but, try as I might, I couldn't find any possibility to use it on a German Windows 7 (64bit): It is easy to draw new construction elements like points, lines and circles. When using, e.g., the pen tool, I can nicely see all these construction elements. But I could not find out how to use these construction elements ind order to, e.g., draw a line that is perpendicular to either another line or to a construction line (or a circle, for that matter). I can switch on snap to construction elements, but no useful snapping takes place. How to tell the software that I want to snap to a perpendicular or a tangent? I am used to such construction helpers since 1992 and have used numerous CAD tools since then, but apparently, Affinity does it quite differently, and I couldn't find out how (it doesn't appear to be obvious to me). The already mentioned link to a Mac forum didn't help me, and I couldn't find this topic in the help, either. Can anybody tell me? Thanks. Andreas Weidner
  14. Affinity Designer 1.7.0.188 on a German Windows 7 (64bit) behaves as follows: When showing the grid & axis manager and using automatic mode, the unnecessary edit fields for distance and subdivisions are shown, but are disabled. When using simple mode, the above mentioned edit fields are completely invisible, making it impossible to set up a simple grid. It would be better if the dialog behaved again as in previous versions. Andreas Weidner NoSimpleGrid.mp4
  15. I just found out about a new beta version of Affinity Photo, so I tried with that one. The error still happens on Beta 1.7.0.188.
×