Jump to content

garrettm30

Members
  • Content Count

    1,133
  • Joined

  • Last visited

About garrettm30

  • Rank
    Dedicated User

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If you are talking about scrolling up and down in the main document area using the mouse wheel, then I do agree that it is much too slow. Here is a brief comparison where I have this thread open in a browser alongside a Publisher document. The low frame rate makes it a little hard to follow, but here is what I was doing: I scrolled down on this thread quickly with one stroke of the wheel, then slowly scrolled back up so you can see how much travel was in a single stroke. Then I tried the same single stroke in Publisher document open beside it. scroll_comparison.mp4 The browser covered about 2.5 times the height of the viewport in a single scroll, while the visible document area in Publisher scrolls by roughly 0.5 of its visible height. This is not precise, but anyone can set up a similar test to feel how Publisher compares side by side, using the same mouse, with other programs. Note that Publisher does respond to macOS preferences scroll speed, so you could increase it, but you would also be proportionally increasing all the other apps which respect it as well, so I choose not increase it because it makes the other apps far too fast. I think all 3rd-party apps should aim to match the scroll speed of 1st-party apps at a given system scroll speed preference, so that no matter what the user chose, it would be consistent across the whole OS.
  2. I'm going to take a stab at this with an idea of one possible explanation. Do you have "Save History with Document" (under the File menu) active? That means all the resources that you previously used in the process of making the document must still be saved in the file in case you choose to undo. To give an example: I started a new document with a resource policy of prefer embedded. Activated "Save History with Document" Placed a 23.3 MB PDF and saved. Saved file: 24.9 MB. Deleted the PDF and changed document image policy to prefer linked. Placed the same PDF and confirmed it is linked via the resource manager. Saved again. Saved file: 26 MB. Unchecked "Save History with Document" and saved again. Saved file: 438 KB. So to answer your original question, the entire linked file would not normally be saved in the document. If you had any embedded resources in the past, even if they are not there now, they would still be saved to the file if you have chosen to "Save History with Document." That is what is happening at step 6 in my example: there is nothing more than one linked PDF in my simple text document, yet the file size reflects that the PDF is still stored inside the document. That is because previously (step 3), there was an embedded copy of that same PDF, and it is saved along with the undo history in case I chose to undo all the way back to step 3. When I decided to discard the save history and save again (step 7), then the past embedded document is no longer saved inside the file. "Save History with Document" can be helpful to use, but it is also good to understand that the file size will be increased, especially when it comes to resources. I do not know if this is the cause in your case, but at least it is a good thing to be aware of.
  3. That is not how macOS usually works, and it has not been that way in my experience. In any case, it is not an issue Serif can really change since this is an OS-level feature. You can just make the non beta the default.
  4. A minor point, but I do agree. However, I can't reproduce on my macOS 10.14.6 with either Publisher 1.8.4 or beta 1.9.1.952. Maybe it is a windows bug, or perhaps there is something going on weird that it is document-specific.
  5. As Walt suggests, I first suggest you look into your macOS System Preferences to confirm which variety of English is activated, as when only one is activated, it says simply “English” without specifying, and Publisher follows the system settings, only presenting you whatever you have activated at the system level. On my system, I have only US English activated, and it reports as simply “English.” I explain more here: If you do have the variety of English you desired selected, then the issue has to do with the dictionary itself. It was not Serif who decided what spellings to use.
  6. First, let's confirm that it is not a setting issue, because there is just such a setting when you export as PDF and click the More button. By the way, welcome to the forum!
  7. I use group styles very rarely for the reasons you mentioned. The only reason I do use them is for things that several child styles have in common but which together are not themselves useful to ever be applied a paragraph style. For body text, for example, I choose to create that as a paragraph style, which would be used for most body text, and then other things like block quotes would be derivative styles of the paragraph style. In that case, group does not work, because all the different variations have the body text in common, but the basic body text is itself a useful style, so there would be no point in having a group and then a main body text paragraph style. The only group style I regularly use is my "Base Text" style group, which is my top-level default in my style hierarchy. I never apply the Base Text style directly, so it makes sense as a group. That said, I suppose even these cases could be done with a paragraph style about the same way. (If I had the time, I would probably benefit from rereading this thread. I probably learned something from it in the past that I have since forgotten.)
  8. No, actually, I do not think continuing this line of discussion further is productive for the purpose of this thread. I’m pretty sure, after you have been around long enough for well over 2000 posts, that you know how tracking works.
  9. At this point, I'm just not following what you're getting at. I haven't been saying anything about centered text, but for justified text, it is as I said before:
  10. That is true that it is a change, which was my entire point. But what I wrote was that inserting a non-breaking space is a last resort that I try to avoid. If I can achieve what I need to with another way, I do that.
  11. That is not true. But perhaps my terminology is not clear. What I meant here by “text stream” is that if you copy and paste it in another app as raw text, the raw text should be identical. That is, no changed or added characters. If all we are talking about is adjusting justification, then it is not necessary to insert or change characters. Instead, we can use things such as tracking, which is format rather than characters. That is, after all, what automatic justification is doing.
  12. Apple still sells brand new Macs with non retina 1080p displays, so I guess it should not be considered obsolete yet on that count.
  13. I agree with you there; naturally with enough work you could get good results with basically any competent layout engine. My point is that multiline composer usually meets the "good enough" threshold with a whole lot less time spent. Even using MS Word? I am very surprised at that. I am not saying you are mistaken or lying, but I am quite amazed. I thought MS Word only works with inter-word spacing, about as basic as it gets, not even capable of using letter spacing for superior result. I am curious: if you were to apply your same skills to do the same job in both Word and something like Publisher, would not your own results in Publisher be superior? I personally would not include Word as a particularly "competent" layout engine. I have always supposed that is not really what its purpose is, but perhaps I am wrong.
  14. There may be something to that. I do most of my work on a retina iMac, but this morning I was working with the grid in a Designer document on my older non-retina iMac at home, and I was surprised at how clunky it looked. Each grid line appeared to be two non-retina pixels thick, whereas I would expect them to be 1 pixel thick to have a similar apparent size as the same grid on a retina display. On my retina display, the grid does have antialiasing as well, but it is not really noticeable. I had to take a screenshot and blow it up to be sure there was antialiasing on it:
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.