Jump to content
You must now use your email address to sign in [click for more info] ×

LionelD

Members
  • Posts

    229
  • Joined

  • Last visited

Recent Profile Visitors

2,361 profile views
  1. Ok, looks like my posts are not disappearing anymore. @Chakie Hi, how far did you get? I ask because I made a toy for you several days ago, not sure if it might still be of interest..
  2. Ok, so MBP is MacBook Pro and AirDrop is an Apple feature that allows you to transfer files between Apple machines wirelessly (I think it’s magic). AirDrop is a relatively new feature, so might not be available on your Apple Mac. I’m sure you’ll find it on any new MacBook Air, but doubt your Mac will offer it. I find that the hardware products today are quite miraculously long-lived. I have an iPod Classic that still works (when I try to use it, which is not often). For me there are a few things that detract from older equipment: none of the newer features (especially security features), and declining ability to run the increasingly demanding applications of today. Performance is usually what pushes me to update. Regards
  3. Hi, I am running the V2 apps on a 2019 11” iPad Pro with the latest iPadOS. I upgraded the V1 apps to V2 when V2 was published. I do not have problems moving files between my iPad and my old MBP right now, but at one point I did have trouble moving files with AirDrop. Turns out that was an AirDrop problem which has since been corrected, no hint of trouble at the moment. I don’t remember exactly when this happened; the problem was easily repeated, and Apple accepted my offer to help define the problem. They were very responsive and helpful. I’d guess that if your iPad is running a recent update you won’t have the AirDrop problem. I can track down an approximate date if you need it; let me know. Regards
  4. Hi, I am now running the latest published AD2. I just looked at this again to determine if it has been fixed. It has not; the behaviour documented above has not changed. But I did learn something. If you open the 01 attached file, you will see that each of the 3 circles is reported to be a Symbol. If you drag one of the 3 circle symbols outside the compound Symbol, it is still reported to be a Symbol, and changing its fill propagates to the 2 circles remaining in the compound Symbol. Exactly what you’d want and expect. However, if you do that with the 02 attached file you get a different result. Opening that file, the 3 circles are reported to be Symbols (with different colors) in the Layers panel. Drag any one of them outside the compound Symbol and it is reported to be a group, not a Symbol. Well, that is inconsistent, and not what I expected, but it does explain the observed behaviour. I was not aware of this behaviour when I first reported this bug, so did not mention it. I hope this information is useful to Affinity, and would be very happy to see this bug fixed. Please. Regards
  5. @hi_designers Hi. You don’t explain what the blue and red blocks of color are, but based on the layer structure in the first screenshot it seems they might be your fill (or background). If that’s so, the layer structure is the problem. You need to ensure that ALL Motif Symbols are above ALL Fill (Background) Symbols. How you do that depends on your ambitions for your Fill. The following suggestion assume your are using a square as your base geometric structure. If a solid Fill satisfies, you can create a single layer below the Motif Symbols that is the same size as your Motif Symbols combined. So, if one Motif Symbol measures 100px X 100px, your Fill should measure 300px X 300px. The Motif Symbols must be positioned so they cover/overlap the Fill exactly. If you want a more elaborate Fill, you could create a set of 9 Fill Symbols, each exactly the same size as a Motif Symbol - so, using my example immediately above, your Fill Symbol must be 100px X 100px. Motif and Fill Symbols must be matching pairs (same size, same position, different name), and they must be positioned so that the group of Motif Symbols exactly cover/overlap the group of Fill Symbols. That will give you a Fill for each Motif Symbol, and you’ll have to make sure the Fill Symbols also tile correctly, so start with solid colors before you attempt gradients. You might find this thread interesting: Download the files from the first entry in that thread; they will get you to my first suggestion above. As a general note, you want your decorative elements (Motifs) to cross the boundaries between Motif Symbols to avoid leaving obvious tracks, but you can’t do that with Fills because layer structures generally don’t cooperate with that practice. I’m interested in how you progress. Regards
  6. Thank you very much! I'll wait for the update, this is not urgent for me. Regards
  7. Hi, this question refers to latest published Designer 2 on MacBook with lates MacOS for my 2016 machine I tried to implement ocio by following the guidance at I almost got there, but now need some help to finalize, please I believe I got the config file downloaded and installed properly because I now have an OCIO adjustment available in the Layers menu, and the 32-bit Preview panel. I tried to test for a successful installation using an existing 16-bit ProPhoto document (I use ProPhoto for all master documents, heritage from photography background) I opened the test document, used Document Setup in Files menu to convert to 32-bit ProPhoto (screenshot 01) I experimented by adding an OCIO adjustment, I get a new layer for the adjustment, the OCIO adjustment panel is completely unresponsive (Screenshot 02). I tried to examine the changes in the 32-Bit Review panel, but the only clickable items are the first 2 in the Display Transform section (ICC Display Transform and Unmanaged - Screenshot 03). The bird changes quite dramatically in response to clicking. Designer Preferences shows the correct path for where I installed the OCIO config (Screenshot 04) Screenshot 05 shows Finder window with ocio config. The config.ocio folder contains 2 copies of the same file - I renamed one, then added a copy with the original name so I have a clue as to what is there... This is my first significant exposure to OCIO, so I'm less than a novice, and I'm sure I have something wrong. Any suggestions will be welcome... Regards
  8. @Dan C Well, thanks for the response. I’m on the lookout for this happening again, but I remember it happening intermittently. I’ll check back through recent files and will definitely update when/if I find something that’s repeatable. Regards
  9. Thanks. Embarrassing. I’ll have to be more careful about that last Transform which was supposed to avoid that issue. Regards
  10. @walt.farrell Sorry, that was rather cryptic. Before I started paying attention to the coordinates of my artboards, I had a lot of trouble with slices that reported locations and sizes with fractional pixels. Then someone explained how Designer establishes its overall coordinate origin, and some of the consequences when ArtBoards are positioned haphazardly. That was a revelation for me, so I started placing ArtBoards deliberately, and hey presto, so many problems just gone. Regards
  11. Ok, here’s a trimmed down document that repeats the misbehaviour. Just one artboard, eliminating some of the potential red herrings. There are two slices; the second one is the troublesome one. In Designer Persona: Find the layer called “3 X 1 Motif Export” and observe width of 2,661px according to Transform. This is a group, and all constituent layers should have the same width, and should be centred at the same position on the ArtBoard. In Export Persona: Delete the slice called “3 X 1 Motif Export” - cause that’s the one I created. Go to Layers, find the source layer, and create a slice from that layer. Go to Slices, select the new slice, and use Transform tool to observe width of 2,662px. Really… Regards Test Slice Size.afdesign
  12. @walt.farrell Well, thanks. However, the whole reason for that final transform is to force objects that have fractional pixel dimensions to surrender them. Those objects arise when the document-specific content has fractional pixels (equilateral triangles, regular hexagons and the like), two or three of the objects that are created early end up with dimensions with fractional pixels due to their intrinsic geometry. But when I make the layers that are to be exported, I force those objects to integral pixel dimensions, minutely distorting those triangles and hexagons - not least because Export Persona does not let you export objects like that, and there’s no image format I know of that tolerates fractional pixel dimensions. I also used to get ambushed by ArtBoards at inappropriate locations, so I reposition them early on. Very annoying when that happens…….
  13. This is latest published Designer 2 on MacBook with most current OS for my 2016 MBP. The Issue My problem is that slices created from layers in Export Persona do not have same width (in Export Persona) as the source layers, as reported by Transform tool in Designer Persona. Slices are 2662px but layers are 2661px wide. Background I have a document that I use as a template even though it’s not saved as one. It includes 16 slices that were created from layers (these are all groups that represent a small section of the host artboard). I sometimes have to edit the constituent layers in these groups, specifically to change their width to a very specific value using Transform (Designer Persona). After getting ambushed a few times I now check individual layers one at a time to make sure they are the correct size, and at the correct location on the artBoard. Each export group is renamed following my naming convention. Groups are completely distinct, with no shared layers. To make sure the derivative slices have the desired name, the first thing I do after switching to Export Persona is to delete the previous slices. I then select all the source layers, and create new slices. My problem is that the 16 slices created this way (from different source groups) are ALL the wrong size - by which I mean that the size of a newly created slice differs from what Transform reports in the Designer Persona - by 1 pixel. Export Persona reports 2662px, Designer Persona claims 2661px - the value I specified when doing the Transform. I’ve checked sizes in Designer Persona before and after creating the slices, and the outcome is always the same: Export wants to give me 2662px from a 2661px-wide group. The 2661px target width is specific to this document, and is based on document-specific content created very early in the edit process. I had another one yesterday with different width requirements, and that worked perfectly. I believe I have the same behaviour on my iPad running latest published AD2 with iPadOS 16.6.1. I’m open to suggestions, can make a document available to Affinity if they provide a link, please. I will provide a document for the forum if it survives sanitizing.
  14. Ok, I just did a test on my iPad. I started by deleting all the previous slices, recreated them from the source layers, save the file and then closed it. Opened my test file from Files, changed layer names and checked slices in Export Persona - slice names did not update. Is there any documentation of preconditions that enable this to work consistently? Regards
×
×
  • Create New...

Important Information

Terms of Use | 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.